14:02:24 <liuyulong> #startmeeting neutron_l3
14:02:24 <openstack> Meeting started Wed Mar 24 14:02:24 2021 UTC and is due to finish in 60 minutes.  The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:27 <openstack> The meeting name has been set to 'neutron_l3'
14:02:33 <liuyulong> Sorry, a bit late.
14:03:08 <lajoskatona> liuyulong: I was late ~8 mins yesterday from all meetings :-)
14:03:41 <liuyulong> lajoskatona, lol
14:03:48 <liuyulong> OK, let's start.
14:04:08 <liuyulong> #topic Announcements
14:04:20 <liuyulong> #link https://etherpad.opendev.org/p/neutron-xena-ptg
14:04:42 <liuyulong> We are at the end of W dev cycle. Now we hve the X ptg on the way.
14:05:35 <liuyulong> #link https://doodle.com/poll/cc2ste3emzw7ekrh?utm_source=poll&utm_medium=link
14:06:00 <liuyulong> This is the time slot for neutron Xena PTG.
14:06:09 <liuyulong> So two things here:
14:06:22 <liuyulong> 1. add your topic to the etherpad
14:10:36 <liuyulong_> Sorry, I lost the connection...
14:11:38 <liuyulong_> 1. add your topic to the etherpad
14:11:38 <liuyulong_> 2. choose the time available based on your time zone
14:11:38 <slaweq> hi
14:11:40 <slaweq> sorry for being late
14:11:45 <liuyulong_> Two things (repeated...)
14:12:03 <liuyulong_> It's a virtual PTG again.
14:12:16 <liuyulong_> Hope to see you guys face to face someday. : )
14:12:21 <liuyulong_> slaweq, Hi
14:12:30 <liuyulong_> OK, no more announcement from me now.
14:12:36 <liuyulong_> Let's move on.
14:13:12 <liuyulong> #topic Bugs
14:13:59 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-March/020903.html
14:14:05 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-March/021064.html
14:14:45 * haleyb wanders in late
14:15:02 <liuyulong> The first one
14:15:57 <liuyulong> Sorry, wrong link
14:15:58 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-March/021230.html
14:16:17 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-March/021064.html
14:16:29 <liuyulong> These two are the last two weeks bug list.
14:16:45 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1919107
14:16:47 <openstack> Launchpad bug 1919107 in neutron "[L3][L2 pop] Is it necessary to enforce enabling the option arp_responder and l2_population?" [High,Confirmed]
14:17:03 <liuyulong> This is a real long story.
14:17:39 <liuyulong> #link https://review.opendev.org/c/openstack/neutron/+/778820
14:18:05 <liuyulong> These two config are enforced for the patch https://review.opendev.org/c/openstack/neutron/+/601336
14:18:55 <liuyulong> But as we can see in the 601336, it will not be a good approch to fix the problem in that way. So it will not be merged.
14:19:21 <liuyulong> But, we have done some pre works.
14:19:51 <liuyulong> Some of them casues the bug of https://bugs.launchpad.net/neutron/+bug/1916761
14:19:53 <openstack> Launchpad bug 1916761 in Ubuntu Cloud Archive ussuri "[dvr] bound port permanent arp entries never deleted" [High,Fix committed]
14:20:19 <liuyulong> So, we need to revert them since the final approch 601336 will not be accepted.
14:20:47 <liuyulong> In the revert patch https://review.opendev.org/c/openstack/neutron/+/778820, I put all the work together.
14:21:30 <haleyb> liuyulong: i was just writing a comment in that one, just noticed something with the release note, otherwise fine
14:21:48 <liuyulong> The import thing is on this https://review.opendev.org/c/openstack/neutron/+/752248.
14:21:55 <liuyulong> haleyb, Sure, I will update
14:22:09 <liuyulong> It has some conflicts on that 752248.
14:22:56 <liuyulong> #link https://review.opendev.org/c/openstack/neutron/+/778820/7/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py
14:23:00 <liuyulong> #link https://review.opendev.org/c/openstack/neutron/+/752248/14/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py
14:23:57 <liuyulong> Hope my change is in the right way.
14:25:45 <liuyulong> IMO, we should not rush to merge this patch. I will run "check experimental" for the neutron-tempest-plugin-dvr-multinode-scenario job.
14:26:02 <liuyulong> To verify the east-west traffic of DVR.
14:26:31 <liuyulong> It is failed now, but it's not the DVR case.
14:26:32 <liuyulong> #link https://497849cb3a7ea1ef6b00-cfc9a6b6175848be06351d4fb9f59b07.ssl.cf5.rackcdn.com/778820/7/experimental/neutron-tempest-plugin-dvr-multinode-scenario/58d1c94/testr_results.html
14:26:44 <lajoskatona> it failed now, not sure if related (test_dns_domain_and_name failed )
14:26:54 <lajoskatona> https://497849cb3a7ea1ef6b00-cfc9a6b6175848be06351d4fb9f59b07.ssl.cf5.rackcdn.com/778820/7/experimental/neutron-tempest-plugin-dvr-multinode-scenario/58d1c94/testr_results.html
14:27:45 <lajoskatona> ok, sorry, seems my irc client delayed things...
14:29:25 <liuyulong> lajoskatona, np, maybe it was my message just running slowly on the internet...
14:30:48 <liuyulong> Another thing related to this is the flows for the l2pop and arp responder.
14:30:51 <liuyulong> #link https://bugs.launchpad.net/networking-bagpipe/+bug/1919104
14:30:52 <openstack> Launchpad bug 1919104 in BaGPipe "[bagpipe_bgpvpn] restart ovs agent only will lose flows" [Undecided,In progress] - Assigned to LIU Yulong (dragon889)
14:31:46 <liuyulong> This ovs-agent extension bagpipe_bgpvpn will handle the l2pop tunnel direct flow and arp responder flow.
14:32:44 <liuyulong> But if arp_responder and l2_population are enforced, then [bagpipe_bgpvpn] actually just do things duplicated to the ovs-agent built-in functions.
14:33:18 <liuyulong> So, after the revert, we can disable the arp_responder and l2_population for ovs-agent.
14:34:19 <liuyulong> But, one more thing is ovs-agent will clean the flows not installed by it. Another conflict with [bagpipe_bgpvpn].
14:34:36 <liuyulong> #link https://review.opendev.org/c/openstack/neutron/+/782345/
14:35:21 <liuyulong> So I created this patch for the bug 1919104, which will skip the l2pop and arp responder stale flow clean during ovs-agent restart if they are not enabled.
14:35:23 <openstack> bug 1919104 in BaGPipe "[bagpipe_bgpvpn] restart ovs agent only will lose flows" [Undecided,In progress] https://launchpad.net/bugs/1919104 - Assigned to LIU Yulong (dragon889)
14:37:44 <liuyulong> OK, the final thing about this is I will take some time to consider the alternative of the patch 601336.
14:38:06 <liuyulong> Maybe we can discuss it in the X ptg.
14:39:42 <liuyulong> Next
14:39:43 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1920975
14:39:45 <openstack> Launchpad bug 1920975 in neutron "neutron dvr should lower proxy_delay when using proxy_arp" [Undecided,In progress] - Assigned to Edward Hope-Morley (hopem)
14:39:52 <liuyulong> #link https://review.opendev.org/c/openstack/neutron/+/782570
14:39:56 <liuyulong> I see the patch here.
14:40:35 <liuyulong> With some comments, maybe the kernel config tunning can workaround this problem. https://review.opendev.org/c/openstack/neutron/+/782570/2/neutron/agent/l3/dvr_fip_ns.py#196
14:41:43 <liuyulong> Next
14:41:44 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1920001
14:41:49 <openstack> Launchpad bug 1920001 in neutron "Creation of floating ip with new rbac policies fails" [High,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:42:01 <liuyulong> It's in the deputy's list.
14:42:08 <liuyulong> And the patch was merged.
14:42:42 <liuyulong> #link https://review.opendev.org/c/openstack/neutron-lib/+/781625
14:43:30 <liuyulong> This is proper fix we can see in the LP comments from slaweq.
14:43:54 <slaweq> yes, it's all related to the new policies
14:44:57 <liuyulong> Looks simple, but a new version of neutron-lib should be added for neutron to get the fix work. That will take some time. :)
14:45:35 <liuyulong> Alright, no more bugs from me now.
14:47:00 <liuyulong> OK, let's move on.
14:47:12 <liuyulong> #topic On demand agenda
14:48:03 <lajoskatona> If you have a few minute please check https://review.opendev.org/c/openstack/neutron-specs/+/767337
14:48:09 <lajoskatona> the spec for BFD
14:48:58 <lajoskatona> I run into several issues with os-ken BFD, and to make it work I had to "move" it to an l2 extension which starts os-ken app
14:49:34 <lajoskatona> I tried to summarize the thing in the spec's backend part
14:51:18 <liuyulong> Maybe this can be a new agent which is not only for "L3 routes", but also for internal connection detect, pr neutron router to physical router.
14:51:22 <liuyulong> s/pr/or
14:51:38 <lajoskatona> possible
14:52:54 <liuyulong> Could the command "ovs-vsctl" work to control the ovsdb for BFD?
14:53:04 <lajoskatona> the main issue with os/ken bfd is that it needs to connect to ovsdb to fetch some dp related thing so even in new agent it need a new bridge to add ports dedicated to BFD as can't connect to the same bridge with 2 controller
14:53:20 <lajoskatona> not sure if this is os-ken limitation os vsdb limitation
14:54:13 <lajoskatona> BFD in os-ken sends packet independently from ovs, but for administration it uses dp information
14:54:51 <liuyulong> #link https://review.opendev.org/c/openstack/neutron-specs/+/767337/13/specs/wallaby/bfd_support.rst@547
14:55:35 <lajoskatona> but as I had now a more or less working PoC I realized that the code has strange conditionals, so another option is that I can totally clean dp related things from it, I think nobody uses BFd in openstack
14:55:51 <liuyulong> For the spec here, my idea is to add the ovs command line examples which is equal to os-ken "app" to explain the real usage.
14:57:22 <lajoskatona> yeah I checked that "manually" and checked ovs' BFD implementation, perhaps that can be simpler
14:58:02 <lajoskatona> but even in that way touching ovs from l3-agent can be strange
14:58:46 <liuyulong> Give you some clue, maybe the BFD implementation in the OVN can help. : )
14:59:32 <liuyulong> OK, time is up.
14:59:35 <liuyulong> Let's end here.
14:59:37 <lajoskatona> liuyulong: I can check
14:59:40 <lajoskatona> thanks
14:59:42 <liuyulong> Thank you guys for attending.
14:59:43 <liuyulong> #endmeeting