14:02:33 <liuyulong> #startmeeting neutron_l3
14:02:34 <openstack> Meeting started Wed Aug 26 14:02:33 2020 UTC and is due to finish in 60 minutes.  The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:37 <openstack> The meeting name has been set to 'neutron_l3'
14:02:44 <liuyulong> Sorry, a bit late
14:03:12 <haleyb> liuyulong: i have many conflicts this morning, but will try and respond if you use my nick
14:03:16 <slaweq> hi
14:03:31 <liuyulong> Sure
14:03:33 <liuyulong> Hi
14:03:37 <liuyulong> #topic Announcements
14:03:41 * slaweq has another meeting in 30 minutes so will be just lurking here
14:03:45 <liuyulong> #link http://eavesdrop.openstack.org/meetings/networking/2020/networking.2020-08-25-14.01.log.html#l-10
14:04:09 <liuyulong> This should be a short meeting, so dont worry
14:04:17 <liuyulong> This is the team annouuncements.
14:04:46 <liuyulong> No other announcements from me, so let's go through the bugs.
14:04:53 <liuyulong> #topic Bugs
14:05:22 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016559.html
14:05:29 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016761.html
14:05:34 <ralonsoh> hi (sorry for being late)
14:05:45 <liuyulong> These are the last 2 weeks bug deputy report list.
14:05:48 <liuyulong> Hi ralonsoh
14:06:00 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1891673
14:06:01 <openstack> Launchpad bug 1891673 in neutron "qrouter ns ip rules not deleted when fip removed from vm" [High,In progress] - Assigned to Edward Hope-Morley (hopem)
14:06:48 <liuyulong> Bence had confirmed the bug.
14:07:07 <liuyulong> IMO, this is related to the mixed deployment between compute node dvr and dvr_snat.
14:07:37 <liuyulong> That is saying the user is running VM in a dvr_snat agent mode node.
14:07:52 <liuyulong> And then try to bind/unbind the floating IP from the instance.
14:08:05 <liuyulong> #link https://review.opendev.org/#/c/746336/
14:08:15 <liuyulong> This is the fix of the bug.
14:08:56 * haleyb will review again later
14:10:17 <liuyulong> But according to the fix, it is a bug of the cache of route rule priority.
14:10:53 <liuyulong> Yes, let's try/review that fix.
14:11:04 <liuyulong> Next
14:11:06 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1891360
14:11:07 <openstack> Launchpad bug 1891360 in neutron "Floating IP agent gateway IP addresses not released when deleting dead DVR L3 agents" [Wishlist,Confirmed]
14:11:26 <liuyulong> Yes, neutron should do this cleanup work.
14:11:46 <slaweq> agree
14:11:49 <liuyulong> A potential way is add some port_delete notification recivier which check the port device_owner.
14:12:14 <liuyulong> Sorry, agent delete notification
14:13:00 <liuyulong> Then dvr DB plugin then can do the related port removal.
14:14:33 <liuyulong> Beyond of this, maybe delete the dvr_agent should take care more cautiously.
14:15:07 <liuyulong> For now, neutron seems to allow delete the agent without any warning or check.
14:15:59 <liuyulong> If a dvr L3 agent has running router with floating IPs, delete the related FIP agent gateway port may have a potential mis-op risk
14:16:57 <haleyb> right, should make sure things get to the dvr_snat node in that case
14:19:13 <liuyulong> So, a standard operation document can be supplied to user when they want to offline a L3 (dvr) agent.
14:19:30 <liuyulong> as a first step work for this bug
14:21:26 <liuyulong> OK, next one
14:21:33 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1891448
14:21:34 <openstack> Launchpad bug 1891448 in neutron "L3 agent mode transition between dvr and dvr_no_external" [Wishlist,New]
14:22:59 <liuyulong> I submitted this since we meet such request locally.
14:24:56 <liuyulong> A way in my mind is to add some notifications like: dvr (change to no_external) -> server -> dvr_snat
14:25:15 <liuyulong> Or, dvr_no_external (change to dvr) -> server -> dvr_snat
14:25:48 <liuyulong> Everytime the agent mode is changed, the L3 agent will re-process the routers.
14:26:50 <liuyulong> During this re-processing procedure, check the floating IP host attributes.
14:26:57 <haleyb> and i can imagine there are some edge cases in transitions
14:30:10 <liuyulong> haleyb, cool, good to know, please add them to the LP. We can discuss in there later.
14:30:34 <liuyulong> Last open one:
14:30:35 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1892405
14:30:36 <openstack> Launchpad bug 1892405 in neutron "Removing router interface causes router to stop routing between all" [High,New]
14:31:40 <liuyulong> I'm confused about "VMs can't reach the HA port (IP)".
14:32:10 <liuyulong> Is that saying the VM is trying to ping the HA port in the snat-namespace?
14:32:52 <liuyulong> The HA port is just used for VRRP of the router HA mechanism.
14:32:58 <haleyb> i wonder if this is related to the HA to centralized issue slawek is fixing?  not a lot of info there, like a backtrace :)
14:33:03 <liuyulong> It is not visible to the end user.
14:34:53 <ralonsoh> maybe is talking about the GW port, I don't know
14:35:05 <ralonsoh> let's ask for more info in the LP bug
14:35:59 <liuyulong> yes, slaweq has marked it to High
14:36:44 <liuyulong> OK, last 3 fixed bugs.
14:36:45 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1892489
14:36:47 <openstack> Launchpad bug 1892489 in neutron "[Prefix delegation] When subnet with PD enabled is added to the router, L3 agent fails on waiting for LLAs to be available" [High,Fix released] - Assigned to Slawek Kaplonski (slaweq)
14:36:49 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1892364
14:36:50 <openstack> Launchpad bug 1892364 in neutron "L3 agent prefix delegation - adding new subnet to the router fails" [Medium,Fix released] - Assigned to Brian Haley (brian-haley)
14:36:54 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1892362
14:36:55 <openstack> Launchpad bug 1892362 in neutron "Restarting L3 agent when PD is used fails due to IPAddressAlreadyExists error" [Medium,Fix released] - Assigned to Slawek Kaplonski (slaweq)
14:37:02 <liuyulong> All thanks to slaweq, great work!
14:37:07 <ralonsoh> ++
14:37:23 <slaweq> thx, all were small issues but in overall caused impossible to run dibbler-client
14:38:17 <liuyulong> Wait, one more bug
14:38:19 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1892200
14:38:20 <openstack> Launchpad bug 1892200 in neutron "Make keepalived healthcheck more configurable" [Wishlist,New]
14:38:26 <liuyulong> It is approved.
14:39:16 <liuyulong> So, cool, it is configurable, not fixed. So I'm fine with it. : )
14:40:03 <liuyulong> OK, no more bugs from me now.
14:41:29 <liuyulong> OK, let's move on.
14:41:34 <liuyulong> #topic On demand agenda
14:42:23 <liuyulong> I noticed that Flavio is trying to backport the OVN port forwarding to stable/ussuri.
14:42:46 <liuyulong> Any thougths?
14:43:04 <ralonsoh> IMO is possible
14:44:26 <liuyulong> #link https://review.opendev.org/#/c/747299/
14:44:41 <liuyulong> We have some discussion in this link.
14:45:00 <liuyulong> #link https://docs.openstack.org/project-team-guide/stable-branches.html#active-maintenance
14:45:13 <liuyulong> There are some rules that prevent from doing such backport.
14:45:49 <ralonsoh> well, you are right on this
14:45:51 <liuyulong> ralonsoh, IMO, every commit is possible to backport. The main concern is should/should not. : )
14:46:20 <ralonsoh> let's raise the discussion in gerrit
14:46:29 <ralonsoh> but as you said, this is a new feature
14:46:49 <liuyulong> Yes, it is new to OVN backend.
14:47:39 <liuyulong> From my experiences, the L3 native implementation of port forwarding takes at least 2 or 3 dev cycles to make it robust.
14:53:58 <liuyulong> OK, let's end here.
14:54:01 <liuyulong> Thank you guys.
14:54:08 <ralonsoh> thanks!
14:54:09 <ralonsoh> bye
14:54:14 <liuyulong> #endmeeting