[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