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

Clint Byrum clint at fewbar.com
Tue Mar 21 20:29:00 UTC 2017

Excerpts from Doug Hellmann's message of 2017-03-15 15:35:13 -0400:
> 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?

etcd provides the ability to "watch" keys. So one would start a thread
that just watches the keys you want to reload on, and when they change
that thread will see a response and can reload appropriately.


see "service Watch"

More information about the OpenStack-dev mailing list