Open Stack

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 <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.
>
> 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