[openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime
doug at doughellmann.com
Mon May 14 22:46:32 UTC 2018
Excerpts from Lance Bragstad's message of 2018-05-14 15:20:42 -0500:
> 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?
I thought keystone had moved away from that direction toward deploying
only within Apache? I may be out of touch, or have misunderstood
More information about the OpenStack-dev