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? --John On 21 Mar 2017, at 14:26, Davanum Srinivas wrote: > Jay, > > the /v3alpha HTTP API (grpc-gateway) supports watch > https://coreos.com/etcd/docs/latest/dev-guide/apispec/swagger/rpc.swagger.json > > -- Dims > > On Tue, Mar 21, 2017 at 5:22 PM, Jay Pipes <jaypi...@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 <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 > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __________________________________________________________________________ > 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
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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