On Wed, Mar 22, 2017 at 3:24 PM, Alex Schultz <aschu...@redhat.com> wrote: > On Wed, Mar 22, 2017 at 7:58 AM, Paul Belanger <pabelan...@redhat.com> wrote: [snip] >> Please correct me if I am wrong, because I still have my container training >> wheels on. I understand the need for etcd, and operators to write their >> configuration into it. Why I am struggling with still, is why you need >> oslo.config to support it. There is nothing stopping an operator today from >> using etcd / confd in a container, right? I can only imagine countless other >> services that run in containers using them. >> > > We want oslo.config to support it as a source for configuration. > Dealing with files in containers is complicated. If we can remove the > requirement to munge configurations for containers, > deployment/updating containers becomes easier. The service container > becomes a single artifact to be deployed with less moving parts which > helps reduce complexity and errors. The process for moving a single > container artifact is a lot easier than moving container and updating > configurations based on where it's landing.
I believe the point is that operators will need to have a solution for non-oslo services, if we want to centralize configuration using etcd. If that's the case, it's unclear what will be the benefit of having direct support for etcd in oslo. I have even a counter example: let's say you want to deploy heat api using httpd (as recommended). You'll deploy it it in a container: you then need confd to manage httpd config, but Heat would then talk directly to etcd? I'm not sure the benefit would be gigantic. To summarize: confd (or something equivalent) needs to be in the equation. Should we "simply" standardize on it? -- Thomas __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
