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