Open Stack

Excerpts from Lingxian Kong's message of 2018-05-16 11:12:01 +1200:
> Hi,
> 
> Maybe I missed the original discussion, I found the 'mutable' configuration
> implementation relies on oslo.service, but is there any guide for the
> projects using cotyledon instead?

oslo.service implements the signal handler natively, but the feature
does not rely on oslo.service. The method in oslo.config that does the
work makes no assumptions about what triggers it. We did this on purpose
to support projects that do not use oslo.service.

I don't know enough about cotyledon to tell you how to do it, but you
need to set up a signal handler so that SIGHUP invokes the
mutate_config_files() method of the ConfigOpts instance being used by
the application.

Doug

> 
> Cheers,
> Lingxian Kong
> 
> On Wed, May 16, 2018 at 2:46 AM Doug Hellmann <doug at doughellmann.com> wrote:
> 
> > 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
> >
> > __________________________________________________________________________
> > 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
> >