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

2018-04-06 Thread Michael Johnson 
Yeah, neutron-lbaas runs in the context of the neutron service (it is
a neutron extension), so would be covered by neutron completing the
goal.

Michael

On Fri, Apr 6, 2018 at 3:37 AM, Sławek Kapłoński  wrote:
> Hi,
>
> Thanks Akihiro for help. I added „neutron-dynamic-routing” task to this story 
> and I will push patch for it soon.
> There is still so many things that I need to learn about OpenStack and 
> Neutron :)
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
>> Wiadomość napisana przez Akihiro Motoki  w dniu 
>> 06.04.2018, o godz. 11:34:
>>
>>
>> Hi Slawek,
>>
>> 2018-04-06 17:38 GMT+09:00 Sławek Kapłoński :
>> Hi,
>>
>> One more question about implementation of this goal. Should we take care 
>> (and add to story board [1]) projects like:
>>
>> In my understanding, tasks in the storyboard story are prepared per project 
>> team listed in the governance.
>> IMHO, repositories which belong to a project team should be handled as a 
>> single task.
>>
>> The situations vary across repositories.
>>
>>
>> openstack/neutron-lbaas
>>
>> This should be covered by octavia team.
>>
>> openstack/networking-cisco
>> openstack/networking-dpm
>> openstack/networking-infoblox
>> openstack/networking-l2gw
>> openstack/networking-lagopus
>>
>> The above repos are not official repos.
>> Maintainers of each repo can follow the community goal, but there is no need 
>> to be tracked as the neutron team.
>>
>> openstack/neutron-dynamic-routing
>>
>> This repo is part of the neutron team. We, the neutron team need to cover 
>> this.
>>
>> FYI: The official repositories covered by the neutron team is available here.
>> https://governance.openstack.org/tc/reference/projects/neutron.html
>>
>> Thanks,
>> Akihiro
>>
>>
>> Which looks that should be probably also changed in some way. Or maybe list 
>> of affected projects in [1] is „closed” and if some project is not there it 
>> shouldn’t be changed to accomplish this community goal?
>>
>> [1] https://storyboard.openstack.org/#!/story/2001545
>>
>> —
>> Best regards
>> Slawek Kaplonski
>> sla...@kaplonski.pl
>>
>>
>>
>>
>> > Wiadomość napisana przez ChangBo Guo  w dniu 
>> > 26.03.2018, o godz. 14:15:
>> >
>> >
>> > 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński :
>> > Hi,
>> >
>> > I took care of implementation of [1] in Neutron and I have couple 
>> > questions to about this goal.
>> >
>> > 1. Should we only change "restart_method" to mutate as is described in [2] 
>> > ? I did already something like that in [3] - is it what is expected?
>> >
>> >  Yes , let's the only  thing.  we need test if that if it works .
>> >
>> > 2. How I can check if this change is fine and config option are mutable 
>> > exactly? For now when I change any config option for any of neutron agents 
>> > and send SIGHUP to it it is in fact "restarted" and config is reloaded 
>> > even with this old restart method.
>> >
>> > good question, we indeed thought this question when we proposal  the 
>> > goal.  But It seems difficult to test  that consuming projects like 
>> > Neutron automatically.
>> >
>> > 3. Should we add any automatic tests for such change also? Any examples of 
>> > such tests in other projects maybe?
>> >  There is no example for tests now, we only have some unit tests  in 
>> > oslo.service .
>> >
>> > [1] 
>> > https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html
>> > [2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html
>> > [3] https://review.openstack.org/#/c/554259/
>> >
>> > —
>> > Best regards
>> > Slawek Kaplonski
>> > sla...@kaplonski.pl
>> >
>> >
>> > __
>> > 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
>> >
>> >
>> >
>> > --
>> > 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 goal] Toggle the debug option at runtime

2018-04-06 Thread Sławek Kapłoński 
Hi,

Thanks Akihiro for help. I added „neutron-dynamic-routing” task to this story 
and I will push patch for it soon.
There is still so many things that I need to learn about OpenStack and Neutron 
:)

—
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




> Wiadomość napisana przez Akihiro Motoki  w dniu 
> 06.04.2018, o godz. 11:34:
> 
> 
> Hi Slawek,
> 
> 2018-04-06 17:38 GMT+09:00 Sławek Kapłoński :
> Hi,
> 
> One more question about implementation of this goal. Should we take care (and 
> add to story board [1]) projects like:
> 
> In my understanding, tasks in the storyboard story are prepared per project 
> team listed in the governance.
> IMHO, repositories which belong to a project team should be handled as a 
> single task.
> 
> The situations vary across repositories.
> 
> 
> openstack/neutron-lbaas
> 
> This should be covered by octavia team.
> 
> openstack/networking-cisco
> openstack/networking-dpm
> openstack/networking-infoblox
> openstack/networking-l2gw
> openstack/networking-lagopus
> 
> The above repos are not official repos.
> Maintainers of each repo can follow the community goal, but there is no need 
> to be tracked as the neutron team.
> 
> openstack/neutron-dynamic-routing
> 
> This repo is part of the neutron team. We, the neutron team need to cover 
> this.
> 
> FYI: The official repositories covered by the neutron team is available here.
> https://governance.openstack.org/tc/reference/projects/neutron.html
> 
> Thanks,
> Akihiro
> 
> 
> Which looks that should be probably also changed in some way. Or maybe list 
> of affected projects in [1] is „closed” and if some project is not there it 
> shouldn’t be changed to accomplish this community goal?
> 
> [1] https://storyboard.openstack.org/#!/story/2001545
> 
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
> 
> 
> 
> 
> > Wiadomość napisana przez ChangBo Guo  w dniu 
> > 26.03.2018, o godz. 14:15:
> >
> >
> > 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński :
> > Hi,
> >
> > I took care of implementation of [1] in Neutron and I have couple questions 
> > to about this goal.
> >
> > 1. Should we only change "restart_method" to mutate as is described in [2] 
> > ? I did already something like that in [3] - is it what is expected?
> >
> >  Yes , let's the only  thing.  we need test if that if it works .
> >
> > 2. How I can check if this change is fine and config option are mutable 
> > exactly? For now when I change any config option for any of neutron agents 
> > and send SIGHUP to it it is in fact "restarted" and config is reloaded even 
> > with this old restart method.
> >
> > good question, we indeed thought this question when we proposal  the 
> > goal.  But It seems difficult to test  that consuming projects like Neutron 
> > automatically.
> >
> > 3. Should we add any automatic tests for such change also? Any examples of 
> > such tests in other projects maybe?
> >  There is no example for tests now, we only have some unit tests  in 
> > oslo.service .
> >
> > [1] 
> > https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html
> > [2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html
> > [3] https://review.openstack.org/#/c/554259/
> >
> > —
> > Best regards
> > Slawek Kaplonski
> > sla...@kaplonski.pl
> >
> >
> > __
> > 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
> >
> >
> >
> > --
> > 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



signature.asc
Description: Message signed with OpenPGP
__
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 goal] Toggle the debug option at runtime

2018-04-06 Thread Akihiro Motoki 
Hi Slawek,

2018-04-06 17:38 GMT+09:00 Sławek Kapłoński :

> Hi,
>
> One more question about implementation of this goal. Should we take care
> (and add to story board [1]) projects like:
>

In my understanding, tasks in the storyboard story are prepared per project
team listed in the governance.
IMHO, repositories which belong to a project team should be handled as a
single task.

The situations vary across repositories.


> openstack/neutron-lbaas
>

This should be covered by octavia team.


> openstack/networking-cisco
> openstack/networking-dpm
> openstack/networking-infoblox
> openstack/networking-l2gw
> openstack/networking-lagopus
>

The above repos are not official repos.
Maintainers of each repo can follow the community goal, but there is no
need to be tracked as the neutron team.


> openstack/neutron-dynamic-routing
>

This repo is part of the neutron team. We, the neutron team need to cover
this.

FYI: The official repositories covered by the neutron team is available
here.
https://governance.openstack.org/tc/reference/projects/neutron.html

Thanks,
Akihiro


>
> Which looks that should be probably also changed in some way. Or maybe
> list of affected projects in [1] is „closed” and if some project is not
> there it shouldn’t be changed to accomplish this community goal?
>

> [1] https://storyboard.openstack.org/#!/story/2001545
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
> > Wiadomość napisana przez ChangBo Guo  w dniu
> 26.03.2018, o godz. 14:15:
> >
> >
> > 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński :
> > Hi,
> >
> > I took care of implementation of [1] in Neutron and I have couple
> questions to about this goal.
> >
> > 1. Should we only change "restart_method" to mutate as is described in
> [2] ? I did already something like that in [3] - is it what is expected?
> >
> >  Yes , let's the only  thing.  we need test if that if it works .
> >
> > 2. How I can check if this change is fine and config option are mutable
> exactly? For now when I change any config option for any of neutron agents
> and send SIGHUP to it it is in fact "restarted" and config is reloaded even
> with this old restart method.
> >
> > good question, we indeed thought this question when we proposal  the
> goal.  But It seems difficult to test  that consuming projects like Neutron
> automatically.
> >
> > 3. Should we add any automatic tests for such change also? Any examples
> of such tests in other projects maybe?
> >  There is no example for tests now, we only have some unit tests  in
> oslo.service .
> >
> > [1] https://governance.openstack.org/tc/goals/rocky/enable-
> mutable-configuration.html
> > [2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html
> > [3] https://review.openstack.org/#/c/554259/
> >
> > —
> > Best regards
> > Slawek Kaplonski
> > sla...@kaplonski.pl
> >
> >
> > 
> __
> > 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
> >
> >
> >
> > --
> > 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 goal] Toggle the debug option at runtime

2018-04-06 Thread Sławek Kapłoński 
Hi,

One more question about implementation of this goal. Should we take care (and 
add to story board [1]) projects like:

openstack/neutron-lbaas
openstack/networking-cisco
openstack/networking-dpm
openstack/networking-infoblox
openstack/networking-l2gw
openstack/networking-lagopus
openstack/neutron-dynamic-routing

Which looks that should be probably also changed in some way. Or maybe list of 
affected projects in [1] is „closed” and if some project is not there it 
shouldn’t be changed to accomplish this community goal?

[1] https://storyboard.openstack.org/#!/story/2001545

—
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




> Wiadomość napisana przez ChangBo Guo  w dniu 26.03.2018, 
> o godz. 14:15:
> 
> 
> 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński :
> Hi,
> 
> I took care of implementation of [1] in Neutron and I have couple questions 
> to about this goal.
> 
> 1. Should we only change "restart_method" to mutate as is described in [2] ? 
> I did already something like that in [3] - is it what is expected?
> 
>  Yes , let's the only  thing.  we need test if that if it works .
> 
> 2. How I can check if this change is fine and config option are mutable 
> exactly? For now when I change any config option for any of neutron agents 
> and send SIGHUP to it it is in fact "restarted" and config is reloaded even 
> with this old restart method.
> 
> good question, we indeed thought this question when we proposal  the 
> goal.  But It seems difficult to test  that consuming projects like Neutron 
> automatically.
> 
> 3. Should we add any automatic tests for such change also? Any examples of 
> such tests in other projects maybe?
>  There is no example for tests now, we only have some unit tests  in 
> oslo.service .
> 
> [1] 
> https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html
> [2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html
> [3] https://review.openstack.org/#/c/554259/
> 
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
> 
> 
> __
> 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
> 
> 
> 
> --
> 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



signature.asc
Description: Message signed with OpenPGP
__
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 goal] Toggle the debug option at runtime

2018-03-27 Thread Jim Rollenhagen 
Glancing at the code[0], it looks like cotyledon has this built in already.
Though, you'll probably want to pass in reload_method='mutate' like the
oslo docs suggest[1].

[0]
https://github.com/sileht/cotyledon/blob/master/cotyledon/oslo_config_glue.py#L68
[1]
https://docs.openstack.org/oslo.config/latest/reference/mutable.html#calling-mutate-config-files



// jim

On Tue, Mar 27, 2018 at 12:20 PM, Michael Johnson 
wrote:

> Does anyone know how this will work with services that are using
> cotyledon instead of oslo.service (for eliminating eventlet)?
>
> Michael
>
> On Mon, Mar 26, 2018 at 5:35 AM, Sławomir Kapłoński 
> wrote:
> > Hi,
> >
> >
> >> Wiadomość napisana przez ChangBo Guo  w dniu
> 26.03.2018, o godz. 14:15:
> >>
> >>
> >> 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński :
> >> Hi,
> >>
> >> I took care of implementation of [1] in Neutron and I have couple
> questions to about this goal.
> >>
> >> 1. Should we only change "restart_method" to mutate as is described in
> [2] ? I did already something like that in [3] - is it what is expected?
> >>
> >>  Yes , let's the only  thing.  we need test if that if it works .
> >
> > Ok, so please take a look at my patch for neutron if that is what we
> should do :)
> >
> >>
> >> 2. How I can check if this change is fine and config option are mutable
> exactly? For now when I change any config option for any of neutron agents
> and send SIGHUP to it it is in fact "restarted" and config is reloaded even
> with this old restart method.
> >>
> >> good question, we indeed thought this question when we proposal
> the goal.  But It seems difficult to test  that consuming projects like
> Neutron automatically.
> >
> > I was asking rather about some manual test instead of automatic one.
> >
> >>
> >> 3. Should we add any automatic tests for such change also? Any examples
> of such tests in other projects maybe?
> >>  There is no example for tests now, we only have some unit tests
> in oslo.service .
> >>
> >> [1] https://governance.openstack.org/tc/goals/rocky/enable-
> mutable-configuration.html
> >> [2] https://docs.openstack.org/oslo.config/latest/reference/
> mutable.html
> >> [3] https://review.openstack.org/#/c/554259/
> >>
> >> —
> >> Best regards
> >> Slawek Kaplonski
> >> sla...@kaplonski.pl
> >>
> >>
> >> 
> __
> >> 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
> >>
> >>
> >>
> >> --
> >> 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
> >
> > —
> > Best regards
> > Slawek Kaplonski
> > sla...@kaplonski.pl
> >
> >
> > 
> __
> > 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 goal] Toggle the debug option at runtime

2018-03-27 Thread Michael Johnson 
Does anyone know how this will work with services that are using
cotyledon instead of oslo.service (for eliminating eventlet)?

Michael

On Mon, Mar 26, 2018 at 5:35 AM, Sławomir Kapłoński  wrote:
> Hi,
>
>
>> Wiadomość napisana przez ChangBo Guo  w dniu 
>> 26.03.2018, o godz. 14:15:
>>
>>
>> 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński :
>> Hi,
>>
>> I took care of implementation of [1] in Neutron and I have couple questions 
>> to about this goal.
>>
>> 1. Should we only change "restart_method" to mutate as is described in [2] ? 
>> I did already something like that in [3] - is it what is expected?
>>
>>  Yes , let's the only  thing.  we need test if that if it works .
>
> Ok, so please take a look at my patch for neutron if that is what we should 
> do :)
>
>>
>> 2. How I can check if this change is fine and config option are mutable 
>> exactly? For now when I change any config option for any of neutron agents 
>> and send SIGHUP to it it is in fact "restarted" and config is reloaded even 
>> with this old restart method.
>>
>> good question, we indeed thought this question when we proposal  the 
>> goal.  But It seems difficult to test  that consuming projects like Neutron 
>> automatically.
>
> I was asking rather about some manual test instead of automatic one.
>
>>
>> 3. Should we add any automatic tests for such change also? Any examples of 
>> such tests in other projects maybe?
>>  There is no example for tests now, we only have some unit tests  in 
>> oslo.service .
>>
>> [1] 
>> https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html
>> [2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html
>> [3] https://review.openstack.org/#/c/554259/
>>
>> —
>> Best regards
>> Slawek Kaplonski
>> sla...@kaplonski.pl
>>
>>
>> __
>> 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
>>
>>
>>
>> --
>> 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
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
> __
> 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 goal] Toggle the debug option at runtime

2018-03-26 Thread Sławomir Kapłoński 
Hi,


> Wiadomość napisana przez ChangBo Guo  w dniu 26.03.2018, 
> o godz. 14:15:
> 
> 
> 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński :
> Hi,
> 
> I took care of implementation of [1] in Neutron and I have couple questions 
> to about this goal.
> 
> 1. Should we only change "restart_method" to mutate as is described in [2] ? 
> I did already something like that in [3] - is it what is expected?
> 
>  Yes , let's the only  thing.  we need test if that if it works .

Ok, so please take a look at my patch for neutron if that is what we should do 
:)

> 
> 2. How I can check if this change is fine and config option are mutable 
> exactly? For now when I change any config option for any of neutron agents 
> and send SIGHUP to it it is in fact "restarted" and config is reloaded even 
> with this old restart method.
>  
> good question, we indeed thought this question when we proposal  the 
> goal.  But It seems difficult to test  that consuming projects like Neutron 
> automatically. 

I was asking rather about some manual test instead of automatic one.

> 
> 3. Should we add any automatic tests for such change also? Any examples of 
> such tests in other projects maybe?
>  There is no example for tests now, we only have some unit tests  in 
> oslo.service .
> 
> [1] 
> https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html
> [2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html
> [3] https://review.openstack.org/#/c/554259/
> 
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
> 
> 
> __
> 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
> 
> 
> 
> -- 
> 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

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl


__
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 goal] Toggle the debug option at runtime

2018-03-26 Thread ChangBo Guo 
2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński :

> Hi,
>
> I took care of implementation of [1] in Neutron and I have couple
> questions to about this goal.
>
> 1. Should we only change "restart_method" to mutate as is described in [2]
> ? I did already something like that in [3] - is it what is expected?
>

 Yes , let's the only  thing.  we need test if that if it works .

>
> 2. How I can check if this change is fine and config option are mutable
> exactly? For now when I change any config option for any of neutron agents
> and send SIGHUP to it it is in fact "restarted" and config is reloaded even
> with this old restart method.
>

good question, we indeed thought this question when we proposal  the
goal.  But It seems difficult to test  that consuming projects like Neutron
automatically.

>
> 3. Should we add any automatic tests for such change also? Any examples of
> such tests in other projects maybe?
>
 There is no example for tests now, we only have some unit tests  in
oslo.service .

>
> [1] https://governance.openstack.org/tc/goals/rocky/enable-
> mutable-configuration.html
> [2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html
> [3] https://review.openstack.org/#/c/554259/
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
> __
> 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
>



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