Open Stack

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

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180514/3de731d8/attachment.sig>