14:00:37 <liuyulong> #startmeeting neutron_l3
14:00:38 <openstack> Meeting started Wed Jan 15 14:00:37 2020 UTC and is due to finish in 60 minutes.  The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:42 <openstack> The meeting name has been set to 'neutron_l3'
14:01:09 <liuyulong> hi there
14:01:11 <slaweq> hi
14:01:55 <liuyulong> #topic Announcements
14:03:08 <liuyulong> All things were mentioned during neutron team meeting yesterday.
14:03:16 <liuyulong> So I guess we can move on then?
14:04:40 <liuyulong> OK, let's move on.
14:04:45 <liuyulong> #topic Bugs
14:05:22 <liuyulong> [neutron] Bug deputy report - Jan 06 to 12
14:05:30 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-January/011955.html
14:05:59 <liuyulong> Let's revisit this bug first.
14:06:03 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1774459
14:06:03 <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:06:12 <ralonsoh> hi
14:06:43 <liuyulong> #link https://review.opendev.org/#/c/601336/
14:06:48 <liuyulong> ^ this is the fix of the bug.
14:07:24 <liuyulong> #link https://review.opendev.org/#/c/653883/
14:07:40 <liuyulong> This should be related to the bug and fix.
14:08:55 <liuyulong> I've tested this with some new based on the problem we met locally. So I created a new bug https://bugs.launchpad.net/neutron/+bug/1859638
14:08:55 <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:10:46 <haleyb> hi
14:11:34 <liuyulong> And back to fix, I've left some comments. Some of them are technical issues, IMO, it should be addressed.
14:12:03 <haleyb> imho #link https://review.opendev.org/#/c/653883/ is ready to merge
14:13:27 <liuyulong> haleyb, yes, looks good to me.
14:14:05 <haleyb> i see your comments on the other one, i've had no time to get back to it recently
14:15:38 <liuyulong> haleyb, sure, we can continue the details in the gerrit.
14:16:18 <haleyb> or if anyone has more cycles... i was hoping it was a quick update but doesn't look it
14:16:44 <liuyulong> Besides I also have an idea to fix the bug when we have no GARP from users VM.
14:19:08 <liuyulong> L2pop and ARP responder will not be considered, ARP request and reply will be flooded to tunnels... (Bad news...)
14:21:08 <liuyulong> ARP reply will be sent to local qr-device and flood to tunnels at same time. Then all routers will be aware of the allowed address mac.
14:27:09 <liuyulong> OK, I will summary these comments to the LP bug or gerrit.
14:28:06 <liuyulong> Next one:
14:28:09 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1858661
14:28:09 <openstack> Launchpad bug 1858661 in neutron "Error when creating a Linux interface" [High,Confirmed]
14:28:56 <liuyulong> slaweq, ralonsoh any updates about this ?
14:29:07 <ralonsoh> liuyulong, no sorry, I didn't have time
14:29:13 <ralonsoh> maybe tomorrow
14:29:30 <slaweq> me neighter
14:30:45 <liuyulong> It blocks the CI in high failure rate, or not?
14:31:16 <ralonsoh> sometimes yes, but this is not a repetitive error
14:32:13 <liuyulong> Alright, not 100% is good news. And we also have this from the deputy bug list:
14:32:27 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1858642
14:32:27 <openstack> Launchpad bug 1858642 in neutron "paramiko.ssh_exception.NoValidConnectionsError error cause dvr scenario jobs failing" [High,Confirmed]
14:32:43 <ralonsoh> yes, I'm on it now
14:36:42 <liuyulong> OK, all these issues can be discussed during CI meeting in details later.
14:36:47 <liuyulong> Next one
14:36:56 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1859163
14:36:56 <openstack> Launchpad bug 1859163 in neutron "Create port with fixed ipv6 address for non-router ports is not allowed anymore" [Medium,Fix committed] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:37:08 <liuyulong> Just updated the status of the bug, it is fixed.
14:37:14 <liuyulong> #link https://review.opendev.org/#/c/701965/
14:37:16 <ralonsoh> cool!
14:37:36 <ralonsoh> waiting for the gate
14:37:57 <liuyulong> Next one
14:37:59 <liuyulong> #link sometimes yes, but this is not a repetitive error
14:38:05 <liuyulong> #undo
14:38:06 <openstack> Removing item from minutes: #link sometimes
14:38:24 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1858419
14:38:24 <openstack> Launchpad bug 1858419 in neutron "Docs needed for tunables at large scale" [Medium,Confirmed] - Assigned to Slawek Kaplonski (slaweq)
14:40:35 <liuyulong> Again, I'm now revisit those patches of scale issues have the config options.
14:40:46 <liuyulong> #link https://review.opendev.org/#/c/364793/
14:40:52 <liuyulong> This can be an example.
14:41:47 <slaweq> thx liuyulong for working on this
14:42:03 <liuyulong> slaweq, np
14:42:59 <liuyulong> That's all from the deputy list. Let's shot a quick scan of LP bug list.
14:44:09 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1858086
14:44:09 <openstack> Launchpad bug 1858086 in neutron "qrouter's local link route cannot be restored " [Medium,Confirmed]
14:45:01 <liuyulong> Assigned to me now, I will try to fix it in neutron-server API to disable such route update.
14:45:28 <slaweq> if You are changing API You should add new api extension to make this change discoverable
14:45:50 <ralonsoh> even if this is an error?
14:45:57 <slaweq> ralonsoh: I think so
14:45:57 <ralonsoh> (just asking)
14:46:00 <ralonsoh> perfect
14:46:04 <slaweq> as we are changing API behaviour
14:46:18 <slaweq> so e.g. we will not be able to test it in tempest properly
14:46:26 <slaweq> (potentially)
14:46:45 <slaweq> so it should be probably some shim extension but still we will need that
14:47:08 <liuyulong> Sure
14:47:54 <liuyulong> No more bugs from me now. Any updates?
14:47:59 <ralonsoh> no
14:48:13 <slaweq> I have one new
14:48:19 <slaweq> https://bugs.launchpad.net/neutron/+bug/1859832
14:48:19 <openstack> Launchpad bug 1859832 in neutron "L3 HA connectivity to GW port can be broken after reboot of backup node" [Medium,New] - Assigned to Slawek Kaplonski (slaweq)
14:48:24 <slaweq> reported just before this meeting
14:48:34 <slaweq> I'm working on some fix for this
14:48:51 <slaweq> but for now only fix which I have in mind requires changes in both L3 and ovs agent
14:50:04 <slaweq> and also second thing
14:50:22 <slaweq> I yesterday sent patch https://review.opendev.org/#/c/702547/ which is (I hope) fix for old issue with dvr routers
14:50:29 <slaweq> please review it when You will have some time
14:50:47 <ralonsoh> sure
14:50:49 <slaweq> and that's all from my side
14:50:55 <liuyulong> Looks like the GARP issue for bug 1859832.
14:50:55 <openstack> bug 1859832 in neutron "L3 HA connectivity to GW port can be broken after reboot of backup node" [Medium,New] https://launchpad.net/bugs/1859832 - Assigned to Slawek Kaplonski (slaweq)
14:51:10 <slaweq> liuyulong: not GARP but MLDv2 packets
14:51:21 <slaweq> as it's related to IPv6 strictly
14:52:48 <liuyulong> yes, no matter which type of packets, the gateway mac will be refreshed to "backup" node in physical switch.
14:53:03 <slaweq> liuyulong: exactly
14:53:30 <slaweq> I was trying to describe as clear as I possible the issue in bug report
14:53:38 <slaweq> I hope it will be clear for You what's going on there
14:54:01 <slaweq> but if not, I can try to explain it e.g. on IRC if You will have any questions
14:54:30 <liuyulong> I have a simple way to verify this issue.
14:56:37 <liuyulong> When you have centralized floating IPs in the snat gateway, you can use "neutron l3-agent-router-add" to add a new HA member to the router, to see if the floating IP traffic is broken.
14:57:07 <slaweq> liuyulong: but it's race and it can happen only sometimes
14:57:25 <slaweq> so it's possible that on not overloaded system when You are adding only one router, it will be fine
14:57:41 <liuyulong> The way I mentioned can 100% reproduce the problem.
14:57:45 <slaweq> but in general it's true what You said, it can break in such case
14:58:16 <liuyulong> So you have any idea to fix the issue?
14:58:58 <slaweq> liuyulong: yes
14:59:24 <slaweq> I want to create port in br-int and add some additional flag to say to ovs agent to not remove dead_vlan_tag
14:59:46 <slaweq> and then, when l3 agent will do all with this port, update ovs port to remove this flag
14:59:53 <slaweq> and than ovs agent will change tag to proper one
15:00:01 <slaweq> that's long story short
15:00:06 <slaweq> but I'm still working on it
15:00:14 <slaweq> I hope to send something to gerrit this week
15:00:30 <liuyulong> All right, time is up. Let's move to our channel.
15:00:36 <liuyulong> slaweq, thanks.
15:00:36 <slaweq> k
15:00:42 <slaweq> o/
15:00:43 <liuyulong> #endmeeting