[openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)
doug at doughellmann.com
Wed Mar 15 19:35:13 UTC 2017
Excerpts from Thomas Herve's message of 2017-03-15 09:41:16 +0100:
> On Wed, Mar 15, 2017 at 12:05 AM, Joshua Harlow <harlowja at fastmail.com> wrote:
> > * How does reloading work (does it)?
> No. There is nothing that we can do in oslo that will make services
> magically reload configuration. It's also unclear to me if that's
> something to do. In a containerized environment, wouldn't it be
> simpler to deploy new services? Otherwise, supporting signal based
> reload as we do today should be trivial.
Reloading works today with files, that's why the question is important
to think through. There is a special flag to set on options that are
"mutable" and then there are functions within oslo.config to reload.
Those are usually triggered when a service gets a SIGHUP or something similar.
We need to decide what happens to a service's config when that API
is used and the backend is etcd. Maybe nothing, because every time
any config option is accessed the read goes all the way through to
etcd? Maybe a warning is logged because we don't support reloads?
Maybe an error is logged? Or maybe we flush the local cache and start
reading from etcd on future accesses?
> > * 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)
> That's confd: https://github.com/kelseyhightower/confd/ . Bonus
> points; it supports a ton of other backends. One solution is to
> provide templates and documentation to use confd with OpenStack.
That sounds like it might also be useful, but is probably a separate
More information about the OpenStack-dev