Open Stack

Excerpts from Lance Bragstad's message of 2018-05-14 18:45:49 -0500:
> 
> On 05/14/2018 05:46 PM, Doug Hellmann wrote:
> > 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
> > something, though.
> 
> Oh - never mind... For some reason I was thinking there was a way to use
> oslo.service and Apache.
> 
> Either way, I'll do some more digging before tomorrow. I have this as a
> topic on keystone's meeting agenda to go through our options [0]. If we
> do come up with something that doesn't involve intercepting signals
> (specifically for the reason noted by Kristi and Jim in the mod_wsgi
> documentation), should the community goal be updated to include that
> option? Just thinking that we can't be the only service in this position.

I think we've left the implementation details up to the project
teams, for just that reason. That said, it would be good to document
how you do it (either formally or with a mailing list thread).

And FWIW, if what you choose to do is monitor a file, that's fine
as a trigger. I suggest not using the configuration file itself,
though, for the reasons mentioned earlier.

Doug

PS - I wonder how Apache deals with reloading its own configuration
file. Is there some sort of hook you could use?

> 
> [0] https://etherpad.openstack.org/p/keystone-weekly-meeting
> 
> >
> > Doug
> >
> > __________________________________________________________________________
> > 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