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