14:03:12 #startmeeting neutron_l3 14:03:13 Meeting started Wed Mar 25 14:03:12 2020 UTC and is due to finish in 60 minutes. The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:03:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:03:16 The meeting name has been set to 'neutron_l3' 14:03:48 hi 14:03:55 hi 14:04:04 hi 14:05:01 OK, let's start. 14:05:05 #topic Announcements 14:05:08 hi 14:05:41 #link http://eavesdrop.openstack.org/meetings/networking/2020/networking.2020-03-24-14.00.log.html#l-11 14:05:51 Recall the team Announcements 14:07:49 Since we are an online community at most time, a virtual PTG should work for our community members. 14:07:54 #link https://www.openstack.org/events/opendev-ptg-2020/ 14:08:27 So the Vancouver PTG is officially cancelled. 14:10:00 I've been working from home about 2 months. 14:11:05 And more days may still be needed. 14:11:11 So, take care of yourself guys. 14:11:35 liuyulong: thx, I'm working from home for last 2 years already ;) 14:11:56 slaweq, cool, good to know that. 14:12:32 slaweq, you are really safe now and then. 14:12:45 OK, according to the bug deputy email 14:12:47 #link http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013510.html 14:12:57 IMO, no L3 bugs last week. 14:13:48 So, anyone has bug to discuss here? Or let's just go next topic. 14:14:14 OK 14:14:20 #topic OVN_L3 14:14:58 #link https://bugs.launchpad.net/neutron/+bug/1867869 14:14:59 Launchpad bug 1867869 in neutron "[OVN] Remove dependency on fip_object" [Low,In progress] - Assigned to zhanghao (zhanghao2) 14:15:12 this is still ongoing 14:15:27 One bug from OVN 14:15:36 we need to know if this will be needed in QoS FIP 14:16:02 so, IMO, I'll wait to remove this dependency 14:17:52 ralonsoh, sure, thank you for the information. Mostly are TODOs from lucasagomes, IMO, he may also have a deep review. 14:18:59 He is already in the list. 14:19:31 Next should be the patch: 14:19:33 #link https://review.opendev.org/#/c/705660/ 14:19:57 I run it locally last week, it works. But it now needs a rebase. 14:20:14 maciejjozefczyk, ^ 14:21:22 I'll ping him in gerrit or IRC 14:22:17 ralonsoh, thanks for testing! 14:22:21 Sure, I will run the rebased code again if I have enough time. : ) 14:22:49 I'll rebase it 14:23:07 #link https://review.opendev.org/#/c/710881/2/doc/source/ovn/gaps.rst 14:23:58 This is from the gaps from between ML2/OVS and OVN, most of them looks like are related to L3. 14:24:45 Ok, so for 'QoS for Layer 3 IPs': This week I tested OVN QoS on FIP - there is a possibility. Its only a matter of proper match in QoS row. 14:25:35 #link: https://mail.openvswitch.org/pipermail/ovs-discuss/2020-March/049857.html 14:25:48 I want to say that "QoS for Layer 3 IPs" has the higher priority from the perspective of cloud provider. 14:26:43 Datacenter could not ensure that every external IPs to reach the max bandwidth at the same time. 14:31:42 maciejjozefczyk, cool, so just logical flows should be added from L3_ovn plugin to north DB, and then ovn-controller, gateway chassis should do the meters installation. 14:33:09 liuyulong, yes. For now we're working on refactor of adding of QoS rows in NBDB table. From this table the Logical Flows are generated. 14:33:36 After a refactor that would be possible to add specific QoS row that will match a FIP 14:33:55 from Core OVN perspective its possible and I tested it manually, N/S traffic is shaped, while E/W not :) 14:36:23 So the OVN DB schema should be refactored first at core OVN? 14:37:52 OK, I found the answer. https://mail.openvswitch.org/pipermail/ovs-discuss/2020-March/049863.html 14:38:31 liuyulong, There is no need to change anything in Core OVN - in relation to QoS on FIP. 14:40:34 "inport == \"96242e8f-602f-4077-984a-5659e84a8c4f\" && ip4.src == 172.24.5.126 && is_chassis_resident(\"cr-lrp-96242e8f-602f-4077-984a-5659e84a8c4f\")" 14:41:17 I'm not quite sure about this, so in gateway chassis, the packet has already be NATed (source IP) to floating IP. 14:41:20 liuyulong, yes, Neutron, while creating the QoS row should define match similar to this oen 14:41:46 But, what about the ingress from outside world, the destination IP is floating IP. 14:42:22 that will be another rule 14:42:28 depending on the rule direction 14:42:43 the OVN qos rules will match the Neutron QoS ones 14:43:01 and will add the needed "match" field in the NB 14:43:15 (matching src/dst IP or whatever is needed) 14:43:19 liuyulong, yes, the match field in the rule will look differently 14:44:10 So, this line is only for egress (from the perspective of VM) to outside world. 14:44:29 yes 14:44:44 ralonsoh, maciejjozefczyk, thank you guys, : ) 14:45:48 OK, no more OVN related things from me then. 14:45:58 Any updates? 14:46:17 OK, let's move on. 14:46:21 #topic On demand agenda 14:46:45 Something related to IPv6 again. 14:47:09 I rebased the patch https://review.opendev.org/#/c/662111/ from Swaminathan, hope we could continue the work. 14:49:34 liuyulong: yes, that would be good to move forward. We should think about OVN as well 14:51:57 haleyb, indeed, we should not introduce another gap. : ) 14:53:55 i know, but knowing it exists and adding it to the list is good, that way it can be worked on. 14:55:17 +1 make sense 14:56:36 I will test Swaminathan's patch more deeply locally, and comment the feedback. 14:57:14 IMO, it is pretty close now. 14:57:38 Alright, no more topics from me now. 15:00:17 Time is up. 15:00:26 Lets end here. 15:00:33 #endmeeting