[openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)
therve at redhat.com
Wed Mar 22 15:19:28 UTC 2017
On Wed, Mar 22, 2017 at 3:24 PM, Alex Schultz <aschultz at redhat.com> wrote:
> On Wed, Mar 22, 2017 at 7:58 AM, Paul Belanger <pabelanger at redhat.com> wrote:
>> 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?
More information about the OpenStack-dev