[openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)

Joshua Harlow harlowja at fastmail.com
Tue Mar 14 23:05:02 UTC 2017


So just fyi, this has been talked about before (but prob in context of 
zookeeper or various other pluggable config backends).

Some links:

- https://review.openstack.org/#/c/243114/
- https://review.openstack.org/#/c/243182/
- https://blueprints.launchpad.net/oslo.config/+spec/oslo-config-db
- https://review.openstack.org/#/c/130047/

I think the general questions that seem to reappear are around the 
following:

* How does reloading work (does it)?

* What's the operational experience (editing a ini file is about the 
lowest bar we can possible get to, for better and/or worse).

* Does this need to be a new oslo.config backend or is it better suited 
by something like the following (external programs loop)::

    etcd_client = make_etcd_client(args)
    while True:
        has_changed = etcd_client.get_new_config("/blahblah") # or use a 
watch
        if has_changed:
           fetch_and_write_ini_file(etcd_client)
           trigger_reload()
        time.sleep(args.wait)

* Is an external loop better (maybe, maybe not?)

Pretty sure there are some etherpad discussions around this also somewhere.

Clint Byrum wrote:
> Excerpts from Davanum Srinivas's message of 2017-03-14 13:04:37 -0400:
>> 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?
>>
>> 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.
>>
>
> This is a cool idea, and I think we should do it.
>
> A few loose ends I'd like to see in a spec:
>
> * Security Security Security. (Hoping if I say it 3 times a real
>    security person will appear and ask the hard questions).
> * Explain clearly how operators would inspect, edit, and diff their
>    configs.
>
> __________________________________________________________________________
> 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



More information about the OpenStack-dev mailing list