[openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)
inc007 at gmail.com
Tue Mar 14 20:19:42 UTC 2017
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:
>> So one more thing popped up again on IRC:
>> 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:
> 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:
> 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
> 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.
>> 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
> Emilien Macchi
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev