Open Stack

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 <slawek at kaplonski.pl> 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
> slawek at kaplonski.pl
>
>
>
>
>> Wiadomość napisana przez Akihiro Motoki <amotoki at gmail.com> w dniu 06.04.2018, o godz. 11:34:
>>
>>
>> Hi Slawek,
>>
>> 2018-04-06 17:38 GMT+09:00 Sławek Kapłoński <slawek at kaplonski.pl>:
>> 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
>> slawek at kaplonski.pl
>>
>>
>>
>>
>> > Wiadomość napisana przez ChangBo Guo <glongwave at gmail.com> w dniu 26.03.2018, o godz. 14:15:
>> >
>> >
>> > 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński <slawek at kaplonski.pl>:
>> > 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
>> > slawek at kaplonski.pl
>> >
>> >
>> > __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: OpenStack-dev-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>