Open Stack

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:
[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