Comment 6 for bug 1804822

I couple of points which are relevant that I think you are missing:

1) The network numbers you list above assume you are downloading all the files over the external network. This is very inefficient and isn't what we recommend today. Optimizing container layers for all the cases (storage, and logical deployment of services, which files go where etc) is very difficult. Rather than guess at things why not simply use a container registry to eliminate the network bandwidth and localize the traffic. In short you should only download a container into each remote edge site once. This is perhaps the primary problem you are dealing with here?

2) In order for our puppet modules to work correctly they have to be executed in a container where the packages exist for the service being configure. Typically this means that keystone config files can only be generated inside of the openstack-keystone container.

3) The way the container images are currently layered you only pull down Puppet once in the base layer.

4) Puppet-TripleO is a packaging problem but your solution isn't a good end game I think. Rather than do what you are suggesting here with a "side" container I would rather see us invest the effort in a slight packaging modification to puppet-tripleo such that it can optionally be installed with only the profiles themselves. The we could layer our service containers so that each one containers only its relevant puppet manifests. For example puppet-keystone would only exist in the openstack-keystone container. NOTE: this will actually duplicate some of the puppet modules and thus require more space but is the correct logical way to package containers I think for deployment and thus trumps the space minor disk space usage a couple of puppet modules would cause.