Open Stack

+1 for having the option. I think in general it is a great idea.

I think there are some devils in the implementation. How do you prevent a service from getting way more secrets then it strictly needs? Maybe this is the start of an activity thought to split out all secrets from config, which would be an awesome thing to do. Having secrets commingled with config has always rubbed me the wrong way.

The other issue I can think of is overridability. the current separate file per instantiated service has some flexibility that a simple implementation of just looking in etcd for the keys may not work for. Some, look here first, then look for overrides over here thing would work though.

Thanks,
Kevin
________________________________________
From: Michał Jastrzębski [inc007 at gmail.com]
Sent: Tuesday, March 14, 2017 1:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)

So from kolla perspective that would be totally awesome. For
kolla-ansible it will make things easier, for kolla-k8s...well, it
would solve a lot (**a lot**) of issues we're dealing with.

Pretty pretty please? <:)

On 14 March 2017 at 10:48, Emilien Macchi <emilien at redhat.com> wrote:
> On Tue, Mar 14, 2017 at 1:04 PM, Davanum Srinivas <davanum at gmail.com> wrote:
>> Team,
>>
>> So one more thing popped up again on IRC:
>> https://etherpad.openstack.org/p/oslo.config_etcd_backend
>>
>> What do you think? interested in this work?
>
> Wow, it seems like our minds are crossing.
> We had this discussion at the PTG and I've seen this topic quite often
> mentioned during different sessions.
>
> It's also somehow mentioned here:
> https://etherpad.openstack.org/p/deployment-pike
> See "Allow services to make use of KV stores instead of just INI files
> for config".
>
> What Thomas is doing in the PoC is actually what we thought it could
> be the next steps forward configuration management in OpenStack in a
> way that could be shared across all tools.
> Partially related, Ben Nemec is working on a spec that would extract
> all OpenStack parameters and generate YAML files:
> https://review.openstack.org/#/c/440835/
> And we thought that we could re-use this file to inject the
> configuration into etcd.
>
> I see a connection here where :
>
> 1. With Ben's work, we would generate a list of parameters available
> in OpenStack and expose it to the User Interface of the deployment
> tool.
> 2. The deployment tool would grab inputs from users and write the
> values into etcd. The installers would also configure some parameters
> that users don't want to provide (with all the logic around).
> 3. OpenStack services would read the config directly from etcd, thanks
> to Thomas's work.
>
> That way, 1. and 3. belong to oslo.config and 2. is done by OpenStack
> deployment tools.
> Does it make sense?
>
> I see a lot of collaboration and consolidation here, in how we do
> configuration management in OpenStack. I hope we can move forward and
> find some consensus here; and why not proposing a first architecture
> for Pike.
>
> Thanks,
>
>> Thanks,
>> Dims
>>
>> PS: Between this thread and the other one about Tooz/DLM and
>> os-lively, we can probably make a good case to add etcd as a base
>> always-on service.
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Emilien Macchi
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev