[openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)
me at not.mn
Tue Mar 21 21:45:59 UTC 2017
I've been following this thread, but I must admit I seem to have missed something.
What problem is being solved by storing per-server service configuration options in an external distributed CP system that is currently not possible with the existing pattern of using local text files?
On 21 Mar 2017, at 14:26, Davanum Srinivas wrote:
> the /v3alpha HTTP API (grpc-gateway) supports watch
> -- Dims
> On Tue, Mar 21, 2017 at 5:22 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>> 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>
>>>>>> * 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
>>>> 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.
>> 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.
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> Davanum Srinivas :: https://twitter.com/dims
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the OpenStack-dev