Open Stack

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 <doug at doughellmann.com
> > <mailto:doug at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev