Open Stack

On Thu, Nov 29, 2018 at 5:31 AM Chris Dent <cdent+os at anticdent.org> 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?

Yes exactly. I don't think we actually do that much based on
individual system facts other than IP's and hostnames. Which is why
generating the config individually on each node seems like a good area
for optimization. Especially when we are talking about large groups of
nodes that will be identical (same number of cores, memory, etc).

>
> > 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.

Is it explained earlier in the thread?
http://lists.openstack.org/pipermail/openstack-dev/2018-November/136582.html

With additional context as to the "why" here:
http://lists.openstack.org/pipermail/openstack-dev/2018-November/136597.html

I'm fairly sure this addresses your question, but happy to offer more
details if not.

-- 
-- James Slagle
--