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?
Cheers,
Lingxian Kong
On Wed, May 16, 2018 at 2:46 AM Doug Hellmann <***@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 <
> ***@doughellmann.com
> > >>>>> <mailto:***@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-***@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-***@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>