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 <sla...@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 > sla...@kaplonski.pl > > > > >> Wiadomość napisana przez Akihiro Motoki <amot...@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 <sla...@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 >> sla...@kaplonski.pl >> >> >> >> >> > Wiadomość napisana przez ChangBo Guo <glongw...@gmail.com> w dniu >> > 26.03.2018, o godz. 14:15: >> > >> > >> > 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński <sla...@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 >> > 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 > > > __________________________________________________________________________ > 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
