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 <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?
I thought keystone had moved away from that direction toward deploying only within Apache? I may be out of touch, or have misunderstood something, though. Doug __________________________________________________________________________ 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
