On 05/14/2018 02:24 PM, Doug Hellmann wrote: > Excerpts from Lance Bragstad's message of 2018-05-14 13:13:51 -0500: >> On 03/19/2018 09:22 AM, Jim Rollenhagen wrote: >>> On Sat, Mar 17, 2018 at 9:49 PM, Doug Hellmann <d...@doughellmann.com >>> <mailto:d...@doughellmann.com>> wrote: >>> >>> Both of those are good ideas. >>> >>> >>> Agree. I like the socket idea a bit more as I can imagine some >>> operators don't want config file changes automatically applied. Do we >>> want to choose one to standardize on or allow each project (or >>> operators, via config) the choice? >> Just to recap, keystone would be listening for when it's configuration >> file changes, and reinitialize the logger if the logging settings >> changed, correct? > Sort of. > > Keystone would need to do something to tell oslo.config to re-load the > config files. In services that rely on oslo.service, this is handled > with a SIGHUP handler that calls ConfigOpts.mutate_config_files(), so > for Keystone you would want to do something similar. > > That is, you want to wait for an explicit notification from the operator > that you should reload the config, and not just watch for the file to > change. We could talk about using file modification as a trigger, but > reloading is something that may need to be staged across several > services in order so we chose for the first version to make the trigger > explicit. Relying on watching files will also fail when the modified > data is not in a file (which will be possible when we finish the driver > work described in > http://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html).
Hmm, these are good points. I wonder if just converting to use oslo.service would be a lower bar then? > >> Would that suffice for the goal? We'd be explicit in checking for >> logging option changes, so modifications to other configuration options >> shouldn't affect anything, should they? > Yes, oslo.config deals with all of that. > > Each configuration option has a flag saying whether or not it is > mutable (defaults to False). When oslo.config is told to "mutate", > it reloads the data sources and reports as warnings any config > options that changed that are not mutable. > > For any options that are marked mutable and have been changed, it > calls the "mutate hooks" that have been registered by calling > ConfigOpts.register_mutate_hook(), passing some information about > which options changed and what changes were made. > > There's a little more information in > https://docs.openstack.org/oslo.config/latest/reference/mutable.html but > I notice that does not cover the hooks. The one for oslo.log is in > http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/log.py#n229 > > For the goal, however, all you need to do is set up some way to trigger > the call to mutate_config_files() and then document that. > >>> I believe adding those things to oslo.service would make them >>> available to all applications. >>> >>> >>> Not necessarily - this discussion started when the Keystone team was >>> discussing how to implement this, given that keystone doesn't use >>> oslo.service. That said, it should be easy to implement in services >>> that don't want this dependency, so +1. >>> >>> // jim >>> >>> >>> __________________________________________________________________________ >>> 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
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