14:00:01 <liuyulong> #startmeeting neutron_l3
14:00:02 <openstack> Meeting started Wed Jan 27 14:00:01 2021 UTC and is due to finish in 60 minutes.  The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:05 <openstack> The meeting name has been set to 'neutron_l3'
14:00:45 <lajoskatona> o/
14:01:09 <liuyulong> hi
14:01:45 <liuyulong> OK, let's start
14:01:56 <liuyulong> #topic Bugs
14:02:08 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-January/020008.html
14:02:13 <ralonsoh> hi
14:02:15 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019878.html
14:02:16 <haleyb> hi
14:02:26 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019781.html
14:02:34 <liuyulong> We have these bug lists.
14:02:40 <liuyulong> ralonsoh, haleyb, Hi
14:02:51 <liuyulong> First one
14:02:53 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1912596
14:02:54 <openstack> Launchpad bug 1912596 in neutron "neutron-server report 500 error when update floating ip port forwarding" [Medium,In progress]
14:03:09 <liuyulong> The error is clear.
14:03:14 <liuyulong> #link https://review.opendev.org/c/openstack/neutron/+/771776
14:04:32 <liuyulong> But the fix may have large a range of impacts.
14:04:38 <liuyulong> #link https://review.opendev.org/c/openstack/neutron/+/771776/1/neutron/objects/base.py
14:04:41 <ralonsoh> exactly
14:04:51 <ralonsoh> this is not a trivial change
14:05:23 <liuyulong> #link https://review.opendev.org/c/openstack/neutron/+/771776/1/neutron/objects/base.py#853
14:05:42 <liuyulong> IMO, the code is trying to copy these lines.
14:06:52 <liuyulong> But, maybe it my oversight some callers that have already catched the inner exception "DBDuplicateEntry".
14:07:25 <ralonsoh> there are, as commented in the patch
14:09:54 <ralonsoh> I think out chairman is having some issues with the connection
14:09:59 <ralonsoh> our*
14:10:41 <liuyulong92> sorry
14:10:46 <liuyulong92> I lost the connection...
14:11:17 <haleyb> ralonsoh: i would agree with your assessment on the patch, "small but remarkable"
14:11:49 <liuyulong> #chair haleyb
14:11:50 <openstack> Current chairs: haleyb liuyulong
14:12:01 <liuyulong> Just in case I lost connection again.
14:12:51 <liuyulong> """But, maybe it my oversight some callers that have already catched the inner exception "DBDuplicateEntry".""""
14:12:57 <liuyulong> Continue the comments..
14:13:38 <liuyulong> "DBDuplicateEntry" is replaced by NeutronDbObjectDuplicateEntry, so some callers may get a new 500, IMO.
14:14:04 <ralonsoh> yes, as commented in the patch, there are update methods expecting the other exception
14:14:20 <ralonsoh> I found one
14:14:28 <ralonsoh> (it's in the patch)
14:15:38 <liuyulong> OK, so let's move these comments to the gerrit.
14:16:17 <liuyulong> Next one
14:16:18 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1911126
14:16:21 <openstack> Launchpad bug 1911126 in neutron "[RFE][L3] add ability to control router SNAT more granularly" [Wishlist,New] - Assigned to LIU Yulong (dragon889)
14:16:43 <liuyulong> This was approved during last drivers meeting.
14:18:02 <liuyulong> Because there was one drivers meeting skipped in 16-01-2021. So I missed last meeting.
14:18:27 <liuyulong> So here, I will answer some question.
14:18:47 <liuyulong> ralonsoh it is not a TC or QoS mechanism.
14:19:31 <liuyulong> It is a 'datapath', or we can call it a "SNAT data path" for the VMs, IPs, subnets under a router.
14:19:45 <ralonsoh> I know
14:19:53 <ralonsoh> what I was proposing was to mark those packets
14:20:10 <ralonsoh> for example, those ones sent from 10.0.10.0/24
14:20:17 <ralonsoh> and use this conntrack mark in tc-tc
14:20:27 <liuyulong> #link https://review.opendev.org/c/openstack/neutron-specs/+/770540/5/specs/wallaby/elastic_snat.rst@217
14:20:29 <ralonsoh> tc is what you use to shape traffic in FIP
14:20:41 <liuyulong> Here I pasted some iptables rules for python L3 agent.
14:21:22 <ralonsoh> I know and I understand your architecture
14:21:39 <ralonsoh> you are doing a kind of FIP nating
14:21:43 <ralonsoh> same as in FIP namespace
14:21:52 <liuyulong> We mark nothing for the snat rules, it is just a SNAT rule in router namespace.
14:22:13 <ralonsoh> I know you don't mark them
14:22:16 <ralonsoh> that was my proposal
14:22:24 <ralonsoh> anyway, I'll comment in the spec
14:22:50 <liuyulong> ralonsoh, we can consider it as a opposite rules from "floating IP port forwarding".
14:23:09 <liuyulong> floating IP port forwarding is DNAT, while this is SNAT.
14:24:55 <liuyulong> saying the TC, linux TC, the "floating SNAT IPs" will have QoS limitation like other floating IP do.
14:25:22 <liuyulong> Because the "floating SNAT IPs" will also be set on the related router external gateway.
14:25:29 <ralonsoh> I'll comment in the spec
14:27:21 <liuyulong> So for the implamentation about this, I may say, we did it in queens branch.
14:27:35 <liuyulong> So I need some time to refactor the code to master branch.
14:27:46 <liuyulong> And time for testing on master branch.
14:28:03 <liuyulong> So IMO, we have lots of times to review the spec at first.
14:28:41 <liuyulong> OK, no more bugs from me now.
14:28:49 <liuyulong> Any updates?
14:29:28 <liuyulong> OK, let's move on.
14:29:29 <liuyulong> #topic On demand agenda
14:29:52 <lajoskatona> If you have some time please check the bfd spec: https://review.opendev.org/c/openstack/neutron-specs/+/767337 , thanks in advance
14:29:59 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1900934
14:30:01 <openstack> Launchpad bug 1900934 in neutron "[RFE][DHCP][OVS] flow based DHCP" [Wishlist,New] - Assigned to LIU Yulong (dragon889)
14:30:15 <liuyulong> lajoskatona, sure, I will do it.
14:30:22 <lajoskatona> I removed the bgp / dynamic-routing related parts
14:30:26 <ralonsoh> sure
14:30:35 <lajoskatona> liuyulong, ralonsoh: thanks
14:33:23 <liuyulong62> sorry... I lost the connection.
14:34:51 <liuyulong> OK, I'm back really.
14:35:43 <liuyulong> lajoskatona, in your uploaded spec,  we will make L3 agent has ability to control the ovs-db (ovs bfd)?
14:36:35 <lajoskatona> yes, actually I checked os-ken and with that it can be done transparently (I hope)
14:36:48 <lajoskatona> I am working on a PoC, but progressing slowly
14:39:45 <liuyulong> OK, cool, you can link the PoC page to the spec's references.
14:40:01 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1900934
14:40:03 <openstack> Launchpad bug 1900934 in neutron "[RFE][DHCP][OVS] flow based DHCP" [Wishlist,New] - Assigned to LIU Yulong (dragon889)
14:40:09 <lajoskatona> I will do
14:40:13 <liuyulong> For this DHCP agent extension for ml2/ovs.
14:40:16 <liuyulong> I have some updates.
14:40:28 <liuyulong> #link https://review.opendev.org/c/openstack/neutron-specs/+/768588/8/specs/wallaby/distributed_dhcp.rst
14:41:00 <liuyulong> The spec is basically completed.
14:42:14 <liuyulong> Oleg Bondarev
14:42:15 <liuyulong> and I had some disscussion on that.
14:43:28 <liuyulong> The main point about Oleg's comments is "how to do upgrade" and "how to assemble the DHCP reponse".
14:44:05 <liuyulong> We can find the answer at:
14:44:16 <liuyulong> https://review.opendev.org/c/openstack/neutron-specs/+/768588/8/specs/wallaby/distributed_dhcp.rst#282
14:44:21 <liuyulong> #link https://review.opendev.org/c/openstack/neutron-specs/+/768588/8/specs/wallaby/distributed_dhcp.rst#181
14:44:57 <liuyulong> Another thing is I've uploaded a patch for this RFE.
14:45:01 <liuyulong> #link https://review.opendev.org/c/openstack/neutron/+/772255
14:45:31 <liuyulong> OK, and and, I created a blueprint for it.
14:45:32 <liuyulong> #link https://blueprints.launchpad.net/neutron/+spec/distributed-dhcp-for-ml2-ovs
14:46:16 <liuyulong> The neutron patch 772255 is for the new config option "disable_traditional_dhcp".
14:46:42 <liuyulong> Let me quote some lines from the patch:
14:46:48 <liuyulong> If this is set to True, '
14:46:49 <liuyulong> 'neutron server will disable: '
14:46:49 <liuyulong> '1. DHCP provisioning block '
14:46:50 <liuyulong> '2. DHCP API extension and scheduler '
14:46:50 <liuyulong> '3. Network scheduling mechanism '
14:46:51 <liuyulong> '4. DHCP RPC/notification'
14:47:50 <liuyulong> And Oleg also left me some kind comments about this patch.
14:48:17 <liuyulong> His main point about this is "how to use this new option".
14:48:37 <liuyulong> An here is my answer: "This can be not only for "distributed DHCP", but has another use case is for some deployment the operators want to offline all DHCP agents when they change the VM IP/metadata provisioning  action from DHCP to config drive."
14:49:21 <liuyulong> So, if you guys have time, please take a look at the spec. Comments are always welcomed. : )
14:49:31 <liuyulong> And the patch. : )
14:49:59 <liuyulong> OK, OK, wordy me.
14:50:04 <liuyulong> No more updates from me now.
14:50:18 <liuyulong> I will leave some mins for the meeting.
14:50:33 <liuyulong> If you have something to discuess, go ahead.
14:54:22 <liuyulong> OK, let's end the meeting here.
14:54:30 <liuyulong> Thank you guys for attending.
14:54:31 <liuyulong> Bye
14:54:34 <ralonsoh> bye
14:54:35 <lajoskatona> Bye
14:54:37 <liuyulong> #endmeeting