On 03/21/2017 04:29 PM, Clint Byrum wrote:
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
Yep. Unfortunately, you won't be able to start an eventlet greenthread
to watch an etcd3/gRPC key. The python grpc library is incompatible with
eventlet/gevent's monkeypatching technique and causes a complete program
hang if you try to communicate with the etcd3 server from a greenlet. Fun!
So, either use etcd2 (the no-longer-being-worked-on HTTP API) or don't
use eventlet in your client service.
Best,
-jay
__________________________________________________________________________
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
