Open Stack

On Thu, 2018-11-29 at 07:38 -0500, Jay Pipes wrote:
> On 11/29/2018 05:29 AM, Chris Dent wrote:
> > On Wed, 28 Nov 2018, Alex Schultz wrote:
> > 
> > [stuff where I'm clearly in over my head, am missing critical
> > context, and don't know what I'm talking about, so just gonna stay
> > out, deleted]
> > 
> > > > Throughout the discussion I've been assuming I must be missing some
> > > > critical detail because isn't the whole point to have immutable
> > > > stuff? Maybe it is immutable and you all are talking about it in
> > > > ways that make it seem otherwise. I dunno. I suspect I am missing
> > > > some bit of operational experience.
> > > 
> > > The application is immutable, but the configs need to be generated
> > > depending on where they end up or the end users desired configuration.
> > > For some service that includes pulling in some information about the
> > > host and including that (SRIOV, pci, etc).
> > 
> > Presumably most of the config is immutable as well and there are
> > only a (relatively) small number of per-instance-of-thing
> > differences?
> > 
> > > Given the vast amount of configurations exposed in each service, i'm
> > > not sure environment variables help here. Additionally that doesn't
> > > solve for non-oslo services (mysql/rabbitmq/etc) so then you'd end up
> > > having two ways of having to configure the containers/services.
> 
> Not sure about RabbitMQ, but certainly MySQL/MariaDB takes command line 
> argument overrides if the container running MySQL server actually has 
> the mysql server as its entrypoint.
the containers come from kolla
https://github.com/openstack/kolla/blob/master/docker/mariadb/Dockerfile.j2

the entry point is the kolla_start script which does a few things to normalise
all the kolla continer "abi" then runs the command specifed via a json file.
https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/mariadb/templates/mariadb.json.j2

so basicaly it makes sure the config files esists and the permissions are correct then calls 
/usr/bin/mysqld_safe



> 
> I'm not actually sure how the Triple-O container for MySQL/MariaDB is 
> constructed, though. I tried finding where MySQL/MariaDB container was 
> constructed in the dozens of tripleo-related repositories on github but 
> gave up. Maybe someone with knowledge of triple-o's internals can point 
> me to that Dockerfile?
ya the fact triplo uses kolla container make them hard to find unless you know
that. alther tripleo uses a template override file to modify the kolla container
a little for tis needs but in generall they should be the same as the vanila kolla ones.
> 
> > The idea is for the environment variables to only be used for the
> > small number of differences, not everything. As what amount to
> > overrides.

i dont know if docker has fixed this but you used to be unable to change
env vars set after a contier was created which mean to go to debug mode logging you had to
destroy and recreate the container  which is annoying  vs config change and sighup
for servies that support mutable config.

> > 
> > What I'm trying to understand is why this trope of container
> > management doesn't apply here:
> > 
> > A: How do I manage configuration _in_ my containers?
> > B: Don't.
> > A: ?
> > B: Manage it from the outside, tell the container its config when it
> >     starts. If the config needs to change, start a new container.
> 
> Precisely my thoughts as well.
> 
> However, if the containers you are using aren't really application 
> containers (having single-process entrypoints) and are really just 
> lightweight VMs in disguise as containers, then you pretty much throw 
> the above trope out the window and are back to square one using legacy 
> [1] configuration management techniques to configure the "containers" as 
> you would configure a baremetal host or VM.
> 
> In any case, it sounds like the triple-o team is attempting to find any 
> ways they can put their containers on a diet, and I fully support that 
> effort, as I'm sure you do as well.
> 
> -jay
> 
> [1] legacy now equals between 3 and 5 years old. :(
>