<div dir="ltr"><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Hi,</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">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?</div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><font face="trebuchet ms, sans-serif">Cheers,<br>Lingxian Kong</font></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, May 16, 2018 at 2:46 AM Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Lance Bragstad's message of 2018-05-14 18:45:49 -0500:<br>
> <br>
> On 05/14/2018 05:46 PM, Doug Hellmann wrote:<br>
> > Excerpts from Lance Bragstad's message of 2018-05-14 15:20:42 -0500:<br>
> >> On 05/14/2018 02:24 PM, Doug Hellmann wrote:<br>
> >>> Excerpts from Lance Bragstad's message of 2018-05-14 13:13:51 -0500:<br>
> >>>> On 03/19/2018 09:22 AM, Jim Rollenhagen wrote:<br>
> >>>>> On Sat, Mar 17, 2018 at 9:49 PM, Doug Hellmann <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a><br>
> >>>>> <mailto:<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>>> wrote:<br>
> >>>>><br>
> >>>>>     Both of those are good ideas.<br>
> >>>>><br>
> >>>>><br>
> >>>>> Agree. I like the socket idea a bit more as I can imagine some<br>
> >>>>> operators don't want config file changes automatically applied. Do we<br>
> >>>>> want to choose one to standardize on or allow each project (or<br>
> >>>>> operators, via config) the choice?<br>
> >>>> Just to recap, keystone would be listening for when it's configuration<br>
> >>>> file changes, and reinitialize the logger if the logging settings<br>
> >>>> changed, correct?<br>
> >>> Sort of.<br>
> >>><br>
> >>> Keystone would need to do something to tell oslo.config to re-load the<br>
> >>> config files. In services that rely on oslo.service, this is handled<br>
> >>> with a SIGHUP handler that calls ConfigOpts.mutate_config_files(), so<br>
> >>> for Keystone you would want to do something similar.<br>
> >>><br>
> >>> That is, you want to wait for an explicit notification from the operator<br>
> >>> that you should reload the config, and not just watch for the file to<br>
> >>> change. We could talk about using file modification as a trigger, but<br>
> >>> reloading is something that may need to be staged across several<br>
> >>> services in order so we chose for the first version to make the trigger<br>
> >>> explicit. Relying on watching files will also fail when the modified<br>
> >>> data is not in a file (which will be possible when we finish the driver<br>
> >>> work described in<br>
> >>> <a href="http://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html</a>).<br>
> >> Hmm, these are good points. I wonder if just converting to use<br>
> >> oslo.service would be a lower bar then?<br>
> > I thought keystone had moved away from that direction toward deploying<br>
> > only within Apache? I may be out of touch, or have misunderstood<br>
> > something, though.<br>
> <br>
> Oh - never mind... For some reason I was thinking there was a way to use<br>
> oslo.service and Apache.<br>
> <br>
> Either way, I'll do some more digging before tomorrow. I have this as a<br>
> topic on keystone's meeting agenda to go through our options [0]. If we<br>
> do come up with something that doesn't involve intercepting signals<br>
> (specifically for the reason noted by Kristi and Jim in the mod_wsgi<br>
> documentation), should the community goal be updated to include that<br>
> option? Just thinking that we can't be the only service in this position.<br>
<br>
I think we've left the implementation details up to the project<br>
teams, for just that reason. That said, it would be good to document<br>
how you do it (either formally or with a mailing list thread).<br>
<br>
And FWIW, if what you choose to do is monitor a file, that's fine<br>
as a trigger. I suggest not using the configuration file itself,<br>
though, for the reasons mentioned earlier.<br>
<br>
Doug<br>
<br>
PS - I wonder how Apache deals with reloading its own configuration<br>
file. Is there some sort of hook you could use?<br>
<br>
> <br>
> [0] <a href="https://etherpad.openstack.org/p/keystone-weekly-meeting" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/keystone-weekly-meeting</a><br>
> <br>
> ><br>
> > Doug<br>
> ><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>