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 <d...@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 < > 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. > > > > 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
