[openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes
james.slagle at gmail.com
Thu Nov 29 13:22:52 UTC 2018
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
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
> 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?
With additional context as to the "why" here:
I'm fairly sure this addresses your question, but happy to offer more
details if not.
-- James Slagle
More information about the openstack-discuss