Open Stack

> On Nov 28, 2018, at 2:27 PM, Alex Schultz <aschultz at redhat.com> wrote:
> 
>> On Wed, Nov 28, 2018 at 11:44 AM Chris Dent <cdent+os at anticdent.org> wrote:
>> 
>>> On Wed, 28 Nov 2018, James Slagle wrote:
>>> 
>>> Why would we even run the exact same puppet binary + manifest
>>> individually 40,000 times so that we can produce the exact same set of
>>> configuration files that differ only by things such as IP address,
>>> hostnames, and passwords?
>> 
>> This has been my confusion and question throughout this entire
>> thread. It sounds like containers are being built (and configured) at
>> something akin to runtime, instead of built once and then configured
>> (only) at runtime. Isn't it more the "norm" to, when there's a security
>> fix, build again, once, and cause the stuff at edge (keeping its config)
>> to re-instantiate fetching newly built stuff?
>> 
> 
> No we aren't building container items, we're building configurations.
> The way it work s in tripleo is that we use the same containers to
> generate the configurations  as we do to run the services themselves.
> These configurations are mounted off the host as to not end up in the
> container.  This is primarily because things like the puppet modules
> assume certain chunks of software/configuration files exist. So we're
> generating the configuration files to be mounted into the run time
> container.  The puppet providers are extremely mature and allow for in
> place editing and no templates which is how we can get away with this
> in containers.  The containers themselves are not build or modified on
> the fly in this case.
> 
> IMHO this is a side effect of configurations (files) for openstack
> services and their service dependencies where we need to somehow
> inject the running config into the container rather than being able to
> load it from an external source (remember the etcd oslo stuff from a
> few cycles ago?).

I thought the preferred solution for more complex settings was config maps. Did that approach not work out?

Regardless, now that the driver work is done if someone wants to take another stab at etcd integration it’ll be more straightforward today. 

Doug