On Tue, Mar 21, 2017 at 3:45 PM, John Dickinson <m...@not.mn> wrote: > 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? >
This effort is partially to help the path to containerization where we are delivering the service code via container but don't want to necessarily deliver the configuration in the same fashion. It's about ease of configuration where moving service -> config files (on many hosts/containers) to service -> config via etcd (single source cluster). It's also about an alternative to configuration management where today we have many tools handling the files in various ways (templates, from repo, via code providers) and trying to come to a more unified way of representing the configuration such that the end result is the same for every deployment tool. All tools load configs into $place and services can be configured to talk to $place. It should be noted that configuration files won't go away because many of the companion services still rely on them (rabbit/mysql/apache/etc) so we're really talking about services that currently use oslo. Thanks, -Alex > > --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 > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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
