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 <harlo...@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. https://coreos.com/etcd/docs/latest/dev-guide/api_reference_v3.html see "service Watch" __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
