Open Stack

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.

The idea is for the environment variables to only be used for the
small number of differences, not everything. As what amount to
overrides.

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.

I'm pretty sure this isn't really germane to the original point of
this thread, so apologies for adding to the noise, but it was hard
to resist. I'll try harder.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent