14:02:04 #startmeeting neutron_l3 14:02:05 Meeting started Wed Apr 22 14:02:04 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:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:09 The meeting name has been set to 'neutron_l3' 14:02:15 Sorry a bit late 14:02:24 hi 14:02:28 hi 14:02:30 hi 14:02:59 OK, let's start 14:03:00 #topic Announcements 14:03:54 #link https://etherpad.opendev.org/p/neutron-victoria-ptg 14:05:15 I have one question the virtual PTG will be place in the UTC timezone or else? 14:05:38 #link http://eavesdrop.openstack.org/meetings/networking/2020/networking.2020-04-21-14.00.log.html#l-63 14:05:54 I see some comments from last team meeting 14:06:45 liuyulong: there are 3 different slots during the day 14:07:03 one of them at least is good for APAC TZ 14:07:21 please check https://doodle.com/poll/xcd82ea6svs5dben and fill which time slots would be good for You 14:07:36 I will try to book some at the end of this week 14:07:38 It's almost 12 hours time difference between Beijing and NY city. 14:10:36 liuyulong: I hope we will somehow manage to do it :) 14:12:30 Sorry lost my network connection 14:13:33 OK 14:13:48 let's move on. 14:14:25 I have no more announcement. And this time slots tool should be applied to all you want to attend the ptg. 14:14:35 #topic Bugs 14:14:45 #link http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014332.html 14:15:06 Ryan Tidwell (tidwellr) was our bug deputy last week, thanks. 14:15:21 First one 14:15:23 #link https://bugs.launchpad.net/neutron/+bug/1872407 14:15:24 Launchpad bug 1798577 in neutron "duplicate for #1872407 [FWaas-DVR]wrong port name in iptables rules" [Medium,In progress] - Assigned to Wang Weijia (wangweij) 14:15:35 It is duplicated to this: https://bugs.launchpad.net/neutron/+bug/1798577 14:15:35 Launchpad bug 1798577 in neutron "[FWaas-DVR]wrong port name in iptables rules" [Medium,In progress] - Assigned to Wang Weijia (wangweij) 14:15:47 And there is a fix: https://review.opendev.org/#/c/606007/ 14:16:52 The fix actually is from our local deployment. Wang Weijia is my colleague. 14:17:18 So maybe we can move forward about the fix. 14:18:43 OK, next one 14:18:45 #link https://bugs.launchpad.net/neutron/+bug/1873761 14:18:45 Launchpad bug 1873761 in neutron "Internal IP leak to physical interface from qrouter in DVR mode" [Undecided,New] 14:18:48 liuyulong: sure, but problem is that we are lack of core reviewers for fwaas 14:18:56 but I will try to check that patch 14:19:10 slaweq, OK, thank you. 14:19:38 I was trying to reproduce the problem locally today. 14:19:56 But unfortunately, not successfully. 14:20:21 that's interesting 14:20:40 IMO it has to be some rare corner case when this issue happens 14:20:43 I will try to reproduce again in a new devstack installation. 14:20:48 or some misconfiguration issue 14:21:09 as I think lajoskatona or rubasov already tried to reproduce it too and also failed 14:21:36 or maybe I mixed 2 different LPs - sorry :) 14:22:12 slaweq, np 14:22:15 I was not working with the 'internal ip leak' bug :-) 14:22:52 rubasov: ok, I probaby made some mistake there :) 14:23:02 np 14:23:44 slaweq, about the config options, I guess the security group driver can be another potential leak point for the bug. 14:24:28 Maybe not 14:25:44 At least the openflow security group driver has the conntrack functionality. 14:26:30 For the bug itself, it could be a security risk for shared networks. 14:28:42 And for the access of floating IPs from the out side world, the Internal IP may also be visible due to such leak. 14:29:03 OK, let's try to reproduce it first. 14:29:06 Next 14:29:12 https://bugs.launchpad.net/neutron/+bug/1873375 14:29:13 Launchpad bug 1873375 in neutron "Can not use vrrp in a dvr openstack environment " [Undecided,New] 14:29:42 IMO, it is duplicated to this: https://bugs.launchpad.net/neutron/+bug/1859638 14:29:42 Launchpad bug 1774459 in neutron "duplicate for #1859638 Update permanent ARP entries for allowed_address_pair IPs in DVR Routers" [High,In progress] - Assigned to Brian Haley (brian-haley) 14:30:54 Then the final bug: https://bugs.launchpad.net/neutron/+bug/1774459 14:30:54 Launchpad bug 1774459 in neutron "Update permanent ARP entries for allowed_address_pair IPs in DVR Routers" [High,In progress] - Assigned to Brian Haley (brian-haley) 14:31:25 This should be a known issue "VIP between dvr east-west networks does not work at all" 14:32:07 liuyulong: isn't this patch https://review.opendev.org/#/c/717319/ addressing this issue? 14:32:35 sorry, https://review.opendev.org/#/c/716302/ is patch for master branch 14:33:00 No, it's not the same. 14:37:36 Due to the dvr_host_mac, there are some cases that the VIP's ARP may not work when the traffic is crossing the east-west subnets. 14:38:02 ok, I see now 14:40:04 This is the fix which is trying to address these issues: https://review.opendev.org/#/c/601336/ 14:40:40 Swaminathan is not so much activity now... 14:42:19 OK, let's move on 14:42:26 #link https://bugs.launchpad.net/neutron/+bug/1873708 14:42:26 Launchpad bug 1873708 in neutron "Floating IP was not removed from the router when the port forwarding deletion was completed" [Low,In progress] - Assigned to ZhouHeng (zhouhenglc) 14:42:45 I'm be able to reproduce the bug locally. 14:43:21 Yes, after "Delete port forwarding", the floating IP is still in the snat-namespace. 14:43:48 #link https://review.opendev.org/#/c/721129/ 14:44:01 This is the fix, it's simple, and it works. 14:45:31 Next one, it is not in the deputy's list. 14:45:34 #link https://bugs.launchpad.net/neutron/+bug/1874211 14:45:34 Launchpad bug 1874211 in neutron "[L3HA] Keepalived 2.x.x tracks state of virtual_ipaddresses interfaces and router now" [Critical,In progress] - Assigned to Slawek Kaplonski (slaweq) 14:46:13 this one is fresh :) 14:46:25 This fix should be this: https://review.opendev.org/#/c/721799/ 14:46:41 LP has another link https://review.opendev.org/721805 14:47:18 the second one is just modification of our ci jobs related to this bug a bit 14:47:25 real fix is https://review.opendev.org/#/c/721799/ 14:47:51 and it works, as can be seen in https://review.opendev.org/#/c/721574/ when checking results of tripleo-ci-centos-8-scenario007-standalone job 14:49:16 slaweq, nice work! Neutron always needs such work when the underlay software changes... 14:49:37 yes, and we need CI coverage to catch it :) 14:50:33 OK, no more bugs from me now. 14:50:47 Any updates? 14:51:26 OK, next topic 14:51:36 #topic OVN_L3 14:52:01 #link https://bugs.launchpad.net/neutron/+bug/1871730 14:52:01 Launchpad bug 1871730 in neutron "[OVN] local conf devstack for a ovn-northd (DB only) node does not work" [Low,In progress] - Assigned to Maciej Jozefczyk (maciej.jozefczyk) 14:52:24 I've run the fix https://review.opendev.org/#/c/719972/ locally, it really works! 14:52:45 liuyulong, thanks to Lajos :) 14:52:48 Thanks to Lajos Katona 14:53:09 maciejjozefczyk, Yep : ) 14:53:37 I have a topic about the OVN L3. 14:54:23 yes? 14:54:43 It is possible to disable built-in router service plugin (and L3-agent), then just use ovn-router to apply the L3 functions? 14:55:58 Impossible I guess. 14:56:30 liuyulong, we explicitly disable q-l3 14:56:32 https://github.com/openstack/neutron/blob/master/devstack/ovn-local.conf.sample#L43 14:57:55 I mean, for the compute node, it is still run ovs-agent, but DVR should not be used. And a centralized ovn-gateway cluster can be run with ovn related stuff only. 14:58:44 Then the floating IPs, internal subnet gateway and east-west traffic could work? 14:59:24 liuyulong, for compute node we don't use ovs-agent at all 14:59:34 liuyulong, have you noticed it somehow running? 15:00:21 maciejjozefczyk, no 15:00:32 maciejjozefczyk, I guess it is impossible, OVN L3 functions is highly coupled to L2 implementation. 15:01:15 maciejjozefczyk, if no ovn-controller in compute node, the L3 functionalities can not work in ovn-gateway node. 15:01:27 OK, time is up... 15:01:42 liuyulong, in call cases while using OVN we need to have running ovn-controller thats a must have 15:01:47 #endmeeting