[openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)
mordred at inaugust.com
Wed Mar 15 03:23:09 UTC 2017
On 03/15/2017 12:05 AM, Joshua Harlow wrote:
> 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
> * 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).
As a person who operates many softwares (but who does not necessarily
operate OpenStack specifically) I will say that services that store
their config in a service that do not have an injest/update facility
from file are a GIANT PITA to deal with. Config management is great at
laying down config files. It _can_ put things into services, but that's
almost always more work.
Which is my way of saying - neat, but please please please whoever
writes this make a simple facility that will let someone plop config
into a file on disk and get that noticed and slurped into the config
service. A one-liner command line tool that one runs on the config file
to splat into the config service would be fine.
> * 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
> if has_changed:
> * 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:
>>> So one more thing popped up again on IRC:
>>> What do you think? interested in this work?
>>> 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
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev