Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Lingxian Kong]

Thanks for your reply, @Doug and @Jim

Cheers,
Lingxian Kong


On Thu, May 17, 2018 at 2:23 AM Jim Rollenhagen 
wrote:

> On Wed, May 16, 2018 at 9:55 AM, Doug Hellmann 
> wrote:
>
>> 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.
>>
>
> This was asked in another thread, see my reply :)
> http://lists.openstack.org/pipermail/openstack-dev/2018-March/128797.html
>
> // jim
> __
> 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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Jim Rollenhagen]

On Wed, May 16, 2018 at 9:55 AM, Doug Hellmann 
wrote:

> 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.
>

This was asked in another thread, see my reply :)
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128797.html

// jim
__
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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Doug Hellmann]

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  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
> > > > > 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 

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Lingxian Kong]

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  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
> > > > 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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Doug Hellmann]

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  > > 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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Lance Bragstad]

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  > 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.

[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




signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Doug Hellmann]

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  >>> > 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.

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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Lance Bragstad]

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 >> > 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?

>
>> Would that suffice for the goal? We'd be explicit in checking for
>> logging option changes, so modifications to other configuration options
>> shouldn't affect anything, should they?
> Yes, oslo.config deals with all of that.
>
> Each configuration option has a flag saying whether or not it is
> mutable (defaults to False). When oslo.config is told to "mutate",
> it reloads the data sources and reports as warnings any config
> options that changed that are not mutable.
>
> For any options that are marked mutable and have been changed, it
> calls the "mutate hooks" that have been registered by calling
> ConfigOpts.register_mutate_hook(), passing some information about
> which options changed and what changes were made.
>
> There's a little more information in
> https://docs.openstack.org/oslo.config/latest/reference/mutable.html but
> I notice that does not cover the hooks. The one for oslo.log is in
> http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/log.py#n229
>
> For the goal, however, all you need to do is set up some way to trigger
> the call to mutate_config_files() and then document that.
>
>>> I believe adding those things to oslo.service would make them
>>> available to all applications. 
>>>
>>>
>>> Not necessarily - this discussion started when the Keystone team was
>>> discussing how to implement this, given that keystone doesn't use
>>> oslo.service. That said, it should be easy to implement in services
>>> that don't want this dependency, so +1.
>>>
>>> // jim
>>>
>>>
>>> __
>>> 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




signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Doug Hellmann]

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  > > 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).

> 
> Would that suffice for the goal? We'd be explicit in checking for
> logging option changes, so modifications to other configuration options
> shouldn't affect anything, should they?

Yes, oslo.config deals with all of that.

Each configuration option has a flag saying whether or not it is
mutable (defaults to False). When oslo.config is told to "mutate",
it reloads the data sources and reports as warnings any config
options that changed that are not mutable.

For any options that are marked mutable and have been changed, it
calls the "mutate hooks" that have been registered by calling
ConfigOpts.register_mutate_hook(), passing some information about
which options changed and what changes were made.

There's a little more information in
https://docs.openstack.org/oslo.config/latest/reference/mutable.html but
I notice that does not cover the hooks. The one for oslo.log is in
http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/log.py#n229

For the goal, however, all you need to do is set up some way to trigger
the call to mutate_config_files() and then document that.

> 
> >
> > I believe adding those things to oslo.service would make them
> > available to all applications. 
> >
> >
> > Not necessarily - this discussion started when the Keystone team was
> > discussing how to implement this, given that keystone doesn't use
> > oslo.service. That said, it should be easy to implement in services
> > that don't want this dependency, so +1.
> >
> > // jim
> >
> >
> > __
> > 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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Lance Bragstad]

On 03/19/2018 09:22 AM, Jim Rollenhagen wrote:
>
> On Sat, Mar 17, 2018 at 9:49 PM, Doug Hellmann  > 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?

Would that suffice for the goal? We'd be explicit in checking for
logging option changes, so modifications to other configuration options
shouldn't affect anything, should they?

>
> I believe adding those things to oslo.service would make them
> available to all applications. 
>
>
> Not necessarily - this discussion started when the Keystone team was
> discussing how to implement this, given that keystone doesn't use
> oslo.service. That said, it should be easy to implement in services
> that don't want this dependency, so +1.
>
> // jim
>
>
> __
> 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



signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Jim Rollenhagen]

On Sat, Mar 17, 2018 at 9:49 PM, Doug Hellmann 
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?

I believe adding those things to oslo.service would make them available to
> all applications.
>

Not necessarily - this discussion started when the Keystone team was
discussing how to implement this, given that keystone doesn't use
oslo.service. That said, it should be easy to implement in services that
don't want this dependency, so +1.

// jim
__
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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Doug Hellmann]

> On Mar 16, 2018, at 6:08 PM, Mohammed Naser  wrote:
> 
>> On Fri, Mar 16, 2018 at 5:34 PM, Jeremy Stanley  wrote:
>>> On 2018-03-16 21:22:51 + (+), Jim Rollenhagen wrote:
>>> [...]
>>> It seems mod_wsgi doesn't want python applications catching SIGHUP,
>>> as Apache expects to be able to catch that. By default, it even ensures
>>> signal handlers do not get registered.[0]
>> [...]
>>> Given we just had a goal to make all API services runnable as a WSGI
>>> application, it seems wrong to enable mutable config for API services.
>>> It's a super useful thing though, so I'd love to figure out a way we can do
>>> it.
>> [...]
>> 
>> Given these are API services, can the APIs grow a (hopefully
>> standardized) method to trigger this in lieu of signal handling? Or
>> if the authentication requirements are too much, Zuul and friends
>> have grown RPC sockets which can be used to inject these sorts of
>> low-level commands over localhost to their service daemons (or could
>> probably also do similar things over UNIX sockets if you don't want
>> listeners on the loopback interface).
> 
> Throwing an idea out there, but maybe listening to file modification
> events using something like inotify could be a possibility?

Both of those are good ideas. I believe adding those things to oslo.service 
would make them available to all applications. 

> 
>> --
>> Jeremy Stanley
>> 
>> __
>> 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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Mohammed Naser]

On Fri, Mar 16, 2018 at 5:34 PM, Jeremy Stanley  wrote:
> On 2018-03-16 21:22:51 + (+), Jim Rollenhagen wrote:
> [...]
>> It seems mod_wsgi doesn't want python applications catching SIGHUP,
>> as Apache expects to be able to catch that. By default, it even ensures
>> signal handlers do not get registered.[0]
> [...]
>> Given we just had a goal to make all API services runnable as a WSGI
>> application, it seems wrong to enable mutable config for API services.
>> It's a super useful thing though, so I'd love to figure out a way we can do
>> it.
> [...]
>
> Given these are API services, can the APIs grow a (hopefully
> standardized) method to trigger this in lieu of signal handling? Or
> if the authentication requirements are too much, Zuul and friends
> have grown RPC sockets which can be used to inject these sorts of
> low-level commands over localhost to their service daemons (or could
> probably also do similar things over UNIX sockets if you don't want
> listeners on the loopback interface).

Throwing an idea out there, but maybe listening to file modification
events using something like inotify could be a possibility?

> --
> Jeremy Stanley
>
> __
> 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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Jeremy Stanley]

On 2018-03-16 21:22:51 + (+), Jim Rollenhagen wrote:
[...]
> It seems mod_wsgi doesn't want python applications catching SIGHUP,
> as Apache expects to be able to catch that. By default, it even ensures
> signal handlers do not get registered.[0]
[...]
> Given we just had a goal to make all API services runnable as a WSGI
> application, it seems wrong to enable mutable config for API services.
> It's a super useful thing though, so I'd love to figure out a way we can do
> it.
[...]

Given these are API services, can the APIs grow a (hopefully
standardized) method to trigger this in lieu of signal handling? Or
if the authentication requirements are too much, Zuul and friends
have grown RPC sockets which can be used to inject these sorts of
low-level commands over localhost to their service daemons (or could
probably also do similar things over UNIX sockets if you don't want
listeners on the loopback interface).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Jim Rollenhagen]

knikolla brought up an interesting wedge in this goal in #openstack-keystone
today.

It seems mod_wsgi doesn't want python applications catching SIGHUP,
as Apache expects to be able to catch that. By default, it even ensures
signal handlers do not get registered.[0]

I can't quickly find uwsgi's recommendations on this, but I'd assume
it would be similar, as uwsgi uses SIGHUP as a signal to gracefully
reload all workers and the master process.

Given we just had a goal to make all API services runnable as a WSGI
application, it seems wrong to enable mutable config for API services.
It's a super useful thing though, so I'd love to figure out a way we can do
it.

Thoughts?

[0]
http://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIRestrictSignal.html
[1]
http://uwsgi-docs.readthedocs.io/en/latest/Management.html#signals-for-controlling-uwsgi


// jim

On Wed, Feb 28, 2018 at 5:27 AM, ChangBo Guo  wrote:

> Hi ALL,
>
> TC approved the  goal [0]  a week ago ,  so it's time to finish the work.
> we also have a short discussion in oslo meeting  at PTG, find more details
> in [1] ,
> we use storyboard to check the goal in  https://storyboard.openstack.
> org/#!/story/2001545.  It's appreciated PTL set the owner in time .
> Feel free to reach me( gcb) in IRC if you have any questions.
>
>
> [0] https://review.openstack.org/#/c/534605/
> [1] https://etherpad.openstack.org/p/oslo-ptg-rocky  From line 175
>
> --
> ChangBo Guo(gcb)
> Community Director @EasyStack
>
> __
> 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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Jean-Philippe Evrard]

Thanks!

On 16 March 2018 at 16:56, Doug Hellmann  wrote:
> Excerpts from Jeremy Stanley's message of 2018-03-16 13:43:00 +:
>> On 2018-03-16 08:34:28 -0500 (-0500), Sean McGinnis wrote:
>> > On Mar 16, 2018, at 04:02, Jean-Philippe Evrard  
>> > wrote:
>> >
>> > > For OpenStack-Ansible, we don't need to do anything for that
>> > > community goal.  I am not sure how we can remove our name from
>> > > the storyboard, so I just inform you here.
>> >
>> > I believe you can just mark the task as done if there is no
>> > additional work required.
>>
>> Yeah, either "merged" or "invalid" states should work. I'd lean
>> toward suggesting "invalid" in this case since the task did not
>> require any changes merged to your source code.
>
> Yes, we've been using "invalid" to indicate that no work was needed.
>
> 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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2018-03-16 13:43:00 +:
> On 2018-03-16 08:34:28 -0500 (-0500), Sean McGinnis wrote:
> > On Mar 16, 2018, at 04:02, Jean-Philippe Evrard  
> > wrote:
> > 
> > > For OpenStack-Ansible, we don't need to do anything for that
> > > community goal.  I am not sure how we can remove our name from
> > > the storyboard, so I just inform you here.
> > 
> > I believe you can just mark the task as done if there is no
> > additional work required.
> 
> Yeah, either "merged" or "invalid" states should work. I'd lean
> toward suggesting "invalid" in this case since the task did not
> require any changes merged to your source code.

Yes, we've been using "invalid" to indicate that no work was needed.

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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Jeremy Stanley]

On 2018-03-16 08:34:28 -0500 (-0500), Sean McGinnis wrote:
> On Mar 16, 2018, at 04:02, Jean-Philippe Evrard  
> wrote:
> 
> > For OpenStack-Ansible, we don't need to do anything for that
> > community goal.  I am not sure how we can remove our name from
> > the storyboard, so I just inform you here.
> 
> I believe you can just mark the task as done if there is no
> additional work required.

Yeah, either "merged" or "invalid" states should work. I'd lean
toward suggesting "invalid" in this case since the task did not
require any changes merged to your source code.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Sean McGinnis]

> On Mar 16, 2018, at 04:02, Jean-Philippe Evrard  
> wrote:
> 
> Hello,
> 
> For OpenStack-Ansible, we don't need to do anything for that community
> goal.  I am not sure how we can remove our name from the storyboard,
> so I just inform you here.
> 
> Jean-Philippe Evrard (evrardjp)

I believe you can just mark the task as done if there is no additional work 
required.


__
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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Claudiu Belu]

Interesting.

I'll take a look as well (Winstackers). Just an FYI, SIGHUP doesn't exist in 
Windows, so for services like nova-compute, neutron-hyperv-agent, 
neutron-ovs-agent, ceilometer-polling we'd have to use something else.

Best regards,

Claudiu Belu


From: Jean-Philippe Evrard [jean-phili...@evrard.me]
Sent: Friday, March 16, 2018 11:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the 
debug option at runtime

Hello,

For OpenStack-Ansible, we don't need to do anything for that community
goal.  I am not sure how we can remove our name from the storyboard,
so I just inform you here.

Jean-Philippe Evrard (evrardjp)

On 28 February 2018 at 05:27, ChangBo Guo  wrote:
> Hi ALL,
>
> TC approved the  goal [0]  a week ago ,  so it's time to finish the work. we
> also have a short discussion in oslo meeting  at PTG, find more details in
> [1] ,
> we use storyboard to check the goal in
> https://storyboard.openstack.org/#!/story/2001545.  It's appreciated PTL set
> the owner in time .
> Feel free to reach me( gcb) in IRC if you have any questions.
>
>
> [0] https://review.openstack.org/#/c/534605/
> [1] https://etherpad.openstack.org/p/oslo-ptg-rocky  From line 175
>
> --
> ChangBo Guo(gcb)
> Community Director @EasyStack
>
> __
> 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

Re: [openstack-dev] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

[Jean-Philippe Evrard]

Hello,

For OpenStack-Ansible, we don't need to do anything for that community
goal.  I am not sure how we can remove our name from the storyboard,
so I just inform you here.

Jean-Philippe Evrard (evrardjp)

On 28 February 2018 at 05:27, ChangBo Guo  wrote:
> Hi ALL,
>
> TC approved the  goal [0]  a week ago ,  so it's time to finish the work. we
> also have a short discussion in oslo meeting  at PTG, find more details in
> [1] ,
> we use storyboard to check the goal in
> https://storyboard.openstack.org/#!/story/2001545.  It's appreciated PTL set
> the owner in time .
> Feel free to reach me( gcb) in IRC if you have any questions.
>
>
> [0] https://review.openstack.org/#/c/534605/
> [1] https://etherpad.openstack.org/p/oslo-ptg-rocky  From line 175
>
> --
> ChangBo Guo(gcb)
> Community Director @EasyStack
>
> __
> 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