14:00:37 #startmeeting neutron_l3 14:00:37 Meeting started Wed Mar 18 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:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:41 The meeting name has been set to 'neutron_l3' 14:00:43 #topic Announcements 14:00:57 hi 14:01:03 #link http://eavesdrop.openstack.org/meetings/networking/2020/networking.2020-03-16-21.00.log.html#l-10 14:01:07 let's recall wha 14:01:15 #undo 14:01:16 Removing item from minutes: #link http://eavesdrop.openstack.org/meetings/networking/2020/networking.2020-03-16-21.00.log.html#l-10 14:01:20 #link http://eavesdrop.openstack.org/meetings/networking/2020/networking.2020-03-16-21.00.log.html#l-10 14:01:38 let's recall the team's Announcements. 14:01:39 hi 14:01:41 hi 14:02:41 Congrats to Lajos Katona. 14:03:03 Welcome to the core team. 14:03:38 ++ 14:04:09 #link https://review.opendev.org/#/admin/groups/38,members 14:04:20 we now have 11 members. 14:05:11 Oh, and ovn cores, it should be 15. 14:05:27 and most of them are active, so I think our team is in good shape now 14:05:30 :) 14:05:49 I also have some another potential candidates in mind, but not for now (yet) :) 14:05:58 hi 14:07:02 Yes, the team are active, and we also have 4 meetings per week. 14:07:57 OK, next topic should be the virtual PTG. 14:08:44 My concern is jet lag, it the virtual PTG will be held a full day, someone may not be available to attend some topics. 14:09:49 I have applied for my travel support and no reply at present. 14:10:13 currently lets just focus on planning topics to discuss 14:10:30 and we will see how it will be :) 14:11:38 I hope that people all over the world can safely defeat the virus. 14:12:46 OK, let's move on. 14:12:51 #topic Bugs 14:13:05 #link http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013352.html 14:15:28 Just one related to L3 OVN: 14:15:32 #link https://bugs.launchpad.net/neutron/+bug/1867122 14:15:34 Launchpad bug 1867122 in neutron "Unnecessary network flapping while update floatingip without port or fixed ip changed" [Low,In progress] - Assigned to Taoyunxiang (taoyunxiang) 14:16:24 It has a fix: https://review.opendev.org/#/c/712641/ 14:16:33 (maybe we should add [OVN] in the title) 14:16:50 It has a tag [OVN] 14:16:51 ralonsoh: we have "ovn" tag which IMO should be enough 14:17:04 perfect 14:19:20 The patch is related to OVN north DB 14:22:08 It's a bit out of our scope again, so let's continue the review in gerrit. 14:22:57 No more L3 bugs from the bug deputy report. So let's have a quick scan of the LP bug list. 14:25:24 Looks like it was a steady and quiet week, one L3 bug from me today. 14:25:38 You guys have any updates? 14:25:55 no 14:25:59 none from me 14:26:00 nope 14:26:38 OK, let's move on. 14:26:43 #topic OVN_L3 14:27:26 lucasagomes, maciejjozefczyk any updates for L3 of OVN? 14:28:20 Alright, they are not here. 14:28:21 liuyulong I would like to ask for review this patch https://review.opendev.org/#/c/705660/ 14:28:31 related to L3, the FIP QoS support is still under investigation 14:28:32 Thats the patch we talked a bit earler, about rescheduling 14:29:07 yes, for now I send e-mail to OVS ml2 if its possible to do QoS on FIP, for not any answer 14:29:53 I *think* without any significant changes in Core OVN its not possible, but im not an expert at all in core ovn 14:30:33 I'm gonna ping our core-ovn team in order to have any insights about it 14:32:06 Yes, I remember that patch, it looks good to me. 14:32:14 thats all what I have about OVN&L3 14:32:19 thanks liuyulong ;) 14:32:35 It can be tested in a all-in-one devstack deployment? 14:34:03 yes, it's possible 14:34:21 I don't remember now, but there are some local.conf examples for this 14:34:30 (I'll send you the links) 14:34:44 I'd like to run that code locally, so I want to know if one node is enough to test it : ) 14:34:44 liuyulong, yes, but I think that needs multinode deployment, at least to have more than one chassis 14:34:56 I worked on it having env with 3 chassis 14:35:11 maciejjozefczyk, did you use devstack? 14:35:25 so 1 node all in one and 2 nodes with only nova-compute and ovn-controllers 14:35:29 ralonsoh, yes, lemme find a likn 14:35:34 thanks!! 14:36:06 ok, so first node: https://github.com/openstack/neutron/blob/master/devstack/ovn-local.conf.sample 14:36:14 and computes: https://github.com/openstack/neutron/blob/master/devstack/ovn-compute-local.conf.sample 14:36:24 that should work, at least worked a few days back :D 14:37:48 Cool, this could be a good advice for reviewers when they want to run the code in a running deployment. 14:38:19 liuyulong, ok, I added a comment there how to test it. 14:38:19 I have a 5 node devstack deployment for neutron agents(none-OVN), one controller, 2 compute nodes and 2 network nodes. : ) 14:40:56 About the OVN FIP QoS, there is a new implementation uploaded 14:40:56 recently. 14:41:52 in Neutron? 14:42:08 well, not for FIP precisely but a refactor of the QoS extension in the OVN client 14:42:18 #link https://review.opendev.org/#/c/712239/ 14:42:23 This one ^ 14:42:32 ahhhhh ok 14:42:36 good to know this 14:42:53 But seems the author just want to run the CI. : ( 14:44:02 With meter actions it changes a lot, I think that not trivial to support FIP on QoS when ovs meter is used. 14:44:36 And for now we just switched QoS to use meters, because normal 'tc' didn't work while the traffic went throught geneve tunnels, 14:44:53 I don't remember the specifics, but ovs meters is the way to go now. 14:45:07 The code seems copied from this: https://review.opendev.org/#/c/539826/ 14:46:09 so the base strategy is to setup the qos on the GW port 14:46:35 https://review.opendev.org/#/c/712239/1/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py@875 14:47:29 ralonsoh, so thats bad right? it will limit N/S traffic for all ports connected to that router. 14:47:37 exactly 14:47:54 this is not like TC, where you can specify the src IP or MAC 14:48:08 if it's qos for fip then it has to be only N/S traffic, right? 14:48:09 to filter the class shaping 14:48:17 ahh, ok 14:48:26 yes, but you should be able to apply a QoS per FIP 14:48:34 but, anyways, thats also needed. I mean from what I remember there is possibility to create QoS on gateway port, right? 14:48:39 here you can only define one QoS OVN rule per direction and port 14:48:44 but ralonsoh changes could also support it out of the box 14:48:47 so there is no way to say "limit only traffic with src/dest == a.b.c.d", correct? 14:48:55 nope 14:48:59 ok, thx 14:49:04 got it now 14:49:14 slaweq, no, we can specify only OVN 'inport', which means OVN Logical_Switch_Port 14:49:45 OVN FIP is only a entry about DNAT/SNAT action 14:50:49 https://review.opendev.org/#/c/712239/1/neutron/common/ovn/qos.py may be here has a clue about it. 14:50:59 get_floating_ip_qos_rules 14:51:09 #link https://mail.openvswitch.org/pipermail/ovs-discuss/2020-March/049801.html 14:51:23 I send an email about it to ovs-discuss ml. 14:51:58 liuyulong, yes, but this is like applying a QoS to a specific port 14:52:04 this is not FIP QOS 14:52:10 liuyulong, hmm, maybe construction like: "'%s == "%s" && ip4.%s == %s && is_chassis_resident("%s")" will solve it, I don't know 14:52:27 Line 26 from proposition 14:52:48 uhhhh 14:52:52 is this possible??? 14:53:02 maciejjozefczyk, yes, that match has an IP address. 14:53:05 I didn't see that in the NB or SB info 14:53:13 maybe the match action is more sophisticated, I mean maybe its able to match more than only inport 14:53:27 yes, it is worth exploring 14:53:45 Cool 14:53:54 with ralonsoh refactor that would be pretty easy to add 14:54:07 for sure 14:54:12 I need to investigate this ASAP 14:54:13 About the QoS, I have an addition, it's the Gateway IP. 14:54:58 QoS on gateway port may limit all traffic like floating IP and SNAT (VMs to outside world without fip). 14:55:18 Gateway IP should be SNAT only. 14:56:36 liuyulong, yes 14:57:25 OK, last topic. 14:57:31 #topic On demand agenda 14:57:49 #link https://bugs.launchpad.net/neutron/+bug/1867119 14:57:50 Launchpad bug 1867119 in neutron "[security] Add allowed-address-pair 0.0.0.0/0 to one port will open all others' protocol under same security group" [Critical,In progress] - Assigned to LIU Yulong (dragon889) 14:57:58 I just updated the patch, reviews are welcomed. 14:58:08 #link https://review.opendev.org/#/c/712632/ 14:58:26 It's not related L3 IMO. : ) 14:59:02 added to my list 14:59:14 liuyulong: I will test it 15:00:10 Thanks : ) 15:00:23 OK, so let's end here. 15:00:27 #endmeeting