14:14:34 #startmeeting neutron_drivers 14:14:34 Meeting started Fri Oct 8 14:14:34 2021 UTC and is due to finish in 60 minutes. The chair is lajoskatona2. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:14:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:14:34 The meeting name has been set to 'neutron_drivers' 14:14:44 Hi, sorry for being late.... 14:14:54 hi 14:14:58 hi 14:15:05 o/ 14:15:26 LOL ihrachys nice new nick :P 14:15:31 pretty long one 14:15:35 yeah. first time connected to this server 14:15:44 not sure if we will have quorum, as mlavalle can't join today 14:17:07 The topic for today: https://bugs.launchpad.net/neutron/+bug/1946251 14:18:07 hi 14:18:18 Hi amotoki 14:19:17 for that rfe I think we would need some "historical" background why it was such coupled always :) 14:20:15 personally I don't see any issues with allowing to disable anti-spoofing and still have SG on the port 14:20:32 but maybe there were good reasons for that in the past :) 14:20:50 a good start would be to formulate what the current port sec API does. it's not really described in api-ref. 14:21:20 so we can only assume, based on historical observations, that it disables both SG and anti-spoof 14:23:22 ihrachys: yes, and neutron is checking really if allowed_address_pairs or SGs are set for port when You want to disable port security 14:23:33 so it's done on purpose I would say 14:24:06 clearly on purpose, so should be documented (in addition to explaining the intent of the API) 14:24:23 I agree that this should be documented :) 14:24:38 yeah, agree. it sould be documented 14:24:41 so assuming it's how neutron defines the API - as disabling both SG and anti-spoof - then the question is - would it make sense to have api to disable one but not the other? 14:24:57 with SGs, it's possible by having a promiscuous SG 14:25:02 and also, regarding Your proposal - I don't think there would be any issue to add possibility to set MAC=ANY in allowed_address_pairs 14:25:13 something like that is already possible for ip_address 14:25:19 as You can set 0.0.0.0 there 14:25:25 Hang Yang proposed openstack/neutron-lib master: Add API extension "security-groups-shared-filtering" https://review.opendev.org/c/openstack/neutron-lib/+/812617 14:25:31 MAC=ANY may confuse L2 switches though 14:25:59 that would be up to driver to interpret it (and declare support for this extension) 14:26:09 but perhaps it would be a responsibility of who use it 14:26:41 alternatively, a new field could be added (port_spoofing_enabled=false) 14:26:56 I mean, anti* 14:27:03 ihrachys: then we should also change logic for "port_security_enabled" field 14:27:12 to not be dependen on allowed_address_pairs anymore 14:27:13 right? 14:27:14 but first, let's maybe discuss if you believe the API is needed at all 14:27:15 ? 14:27:37 slaweq no why? we would keep original behavior, no? 14:28:20 I see slaweq said it's possible to do it, and that it won't be hard to. now the question is, should we? 14:28:50 why should we change this behaviour? 14:29:01 ihrachys: I'm not sure - just thinking 14:29:15 FYI: from my memory, anti-spoofing mechanism was introduced to make SG (remote group) works properly. then allowed-address-pairs was introduced to allow a port to have more IPs. After that (or at almost same time) port_security was introduced to skip all checks. No discussion more than that happened. 14:29:28 how this new attribute port_antispoofing_enabled=false would work if we would have allowed_address_pairs for example? 14:30:02 and if we would have that field, why we would still need to check if there are allowed_address_pairs set for port if port_security_enabled would be set to False? 14:30:08 the particular synthetic scenario our perf folks envisioned is having a VM with 2 VF ports (offloaded) that copies traffic from one port to another verbatim and sends it further. so whatever is received, is sent through another part, regardless of MACs. and the perf measurements are for ACL layer of OVN (=>SGs). So they would want to have SGs but not care about MACs. 14:31:23 slaweq sure, with this new field=true, allowed_address_pairs would not be allowed (similar to what port_sec api does already with both SG and AAP) 14:31:24 Why adding a new extension if we have "port_security_enabled"? 14:31:36 IMHO the easiest way would be to add possibility of MAC=ANY in allowed_address_pairs to do that 14:31:41 ralonsoh because it disables both ACLs and anti-spoofing (apparently) 14:31:56 and some may want to have SG but not the other 14:32:09 not ACLs, but I'll need to check that 14:32:23 SGs are verbotten with port_sec=false 14:32:31 checked on POST 14:33:45 I found this old bug where the discussion can be interesting: https://bugs.launchpad.net/neutron/+bug/1453667 14:33:59 yes, currently SGs and allowed_address_pair are possible only when port_security_enabled = True 14:35:32 lajoskatona this is the patch that added api-ref explaining how attribute behaves (cascades) though it didn't add to explaining what the API is fo 14:35:33 *for 14:36:16 but I assume port_sec=false == (SG=off AND anti-spoofing=off) as per code and historical observations 14:36:25 so just doc update needed there 14:36:42 that's correct currently IMO 14:36:51 yes, my undertsanding is that it was just assumed that the 2 work together, and if we disable one the other should be down as well 14:37:27 but if You would add new parameter port_antispoofing_enabled - this new attr would be used to enable/disable allowed_address_pairs 14:37:34 but otherwise I can't see why we cant decouple the 2, allowed-address -pairs and sec-groups 14:37:38 and port_Security would be related only to SGs 14:37:44 amotoki said "then allowed-address-pairs was introduced to allow a port to have more IPs" but it's a pair so probably also meant to allow more MACs 14:37:45 or am I misunderstanding it? 14:38:12 slaweq no you can't change behavior for existing API 14:38:15 slaweq: yeah that's my understanding 14:38:21 so port_sec would still do what it does now - disable both 14:38:35 right, we can't change current API 14:38:44 and if I understand well the MAC=any or multimac is another feature, 14:38:46 ihrachys: yeah, IIRC more (IP, MAC) pair is allowed and it is expected 14:38:48 but we can add the anti-spoofing API 14:39:35 so keeping old behaviour for "port_sec" and adding new switch only for allowed_address_pairs is a bit weird for me from user Pov 14:39:41 and then we may have a new API (either reusing AAP or a new field) that would control just anti-spoofing (effectively defining a ANY MAC in allowed-address-pair - whether it's actually done by overloading mac field in AAP API or with a new field is a minor detail) 14:40:13 and IMO we should simly allow to set ANY MAC in the AAP field 14:40:19 as we already allow for IP addresses there 14:40:33 and by that kind of "bypass" antispoofing protection for port 14:40:36 slaweq: +1 14:40:45 slaweq it sucks I admit. yes, overloading seems like a more clean way of doing it but I may be wrong. 14:41:08 but that will require support from each specific backend FW 14:41:18 note for IPs we do masks, where /0 means ANY 14:41:26 I don't know if this is possible in OVS FW or iptables or OVN 14:41:27 for MACs, I guess masks are useless, or? 14:41:33 Daniel Alvarez proposed openstack/neutron master: [ovn] Clean up MAC_Binding entries with ovsdb-client https://review.opendev.org/c/openstack/neutron/+/812805 14:41:45 lucasagomes: ^ 14:41:56 75 GB down to 7GB \o/ 14:42:01 ihrachys: You're right 14:42:01 ralonsoh can 14:42:08 dalvarez, ohh yeah 14:43:40 ralonsoh sorry... can't ml2 handle it on its level? "if there's ANY AAP, disable spoofing". (I don't really know how port_sec=disabled works) 14:44:24 what do you mean by ANY AAP? Any IP or Any MAC? 14:44:30 ANY MAC AAP 14:44:48 (I am not shouting, it's acronym soup) 14:44:55 to be honest, I need to see the implementation. But of course, it worths to go this direction 14:45:05 ihrachys: for ANY IP address in AAP agent will add /0 IP into ipset or OF rules in br-int 14:45:23 to allow egress traffic with IPs from that CIDR from this port 14:46:12 I don't know how hard it may be to do the same for "ANY" MACs eg. in ovs case 14:46:38 in OVS we can disable "provides_arp_spoofing_protection" in the FW 14:46:49 well, for all of them, never mind 14:46:58 ok. if each backend needs to implement it, then they will claim back to ml2 that they support this new API extension (we'll have one, right? just to indicate that it's supported - or not) 14:47:15 this way the port_security_enabled=False would swithch off both sec-groups and AAP, but if ANY MAC is there only AAP is down and sec-groups still work for the port, am I getting it right? 14:47:48 yes, that's what I understand 14:47:59 I would say that if You want completly disable antispoofing and keep SG You need to add AAP with ip_address=0/0,MAC=ANY 14:48:04 ralonsoh and if we go with ANY special value, do we support e.g. MAC=ANY and IP=10.0.0.0/24? 14:48:09 that would disable it completly, no? 14:48:31 I am a bit confused. why do we need to downe AAP if ANY MAC is specified? 14:48:32 ihrachys, I need to check that in iptables and OVS FW 14:48:53 s/downe/down/ 14:48:56 lajoskatona that's my understanding, yes 14:49:53 amotoki right. that's the question - does ANY mean allow anything at all, or does it mean "allow anything FROM the ip range with any MAC" 14:50:10 if it's a flag like port_security, it's the former 14:50:41 if we extend AAP API, it may be the latter (actually it would be confusing if it would disable every check, regardless of what we post as IP part of the pair. 14:50:54 if a flag like thing than I would make it simpler like allowed_address_pairs=False or similar 14:51:23 what do you mean "simpler" 14:51:56 I think ANY MAC just means we trust MAC address in packets sent thru such port. I think IP filtering can still be used but I am not sure there is such use case, 14:52:10 simpler for the user like to disable allowed_address_pair=ip=a.b.c.d/0mac=ANY or allowed_addres_pair=False 14:52:15 isn't allowed_address_pairs attribute already occupied by a "list of AAPs" and we can't redefine it as bool? not sure I understood the suggestion. 14:52:52 yeah for that the API would be changed to allow list or bool, that's true 14:53:23 I don't think it's good idea to accept 2 types as the allowed_address_pairs 14:54:08 list or bool sounds like not the best API 14:54:24 ihrachys++ 14:54:46 ok, than it's not a simple flag, we have to always fill the whole ip=...mac=.... fields 14:55:16 in generall I agree with idea to allow disabling antispoofing and keep SG for ports if that's needed - but I really don't know what's the best way to do it 14:55:35 if I were to expand AAP API, I would 1) allow ANY as mac_address in the API and 2) honor the ip_address part of the pair (if it's not /0). Seems like the path of least confusion. This may require some backend work to support the new API extension (which seems like something they will have to do anyway) 14:55:47 do we need a spec for it to see more details written? 14:56:21 ihrachys: so to disable antispoofing You would need to set ip_address=0/0,MAC=ANY as AAP, like I wrote above, right? 14:56:32 I can write something up the next week if that helps. I would try as described above if you think it's ok. 14:56:39 slaweq yes, that would kill all checks 14:57:06 lajoskatona: +1 for spec with short description of various possible solutions for that 14:57:14 why IP address check needs to be disabled? IP of AAP is also used in remote group in SG API 14:57:34 and if someone for some reason (probably for their synthetic test scenario) still needs IP matching - ok, let them do it. though AFAIR that can already be achieved by SG API so that's a bit duplicative 14:59:01 Not sure if we have now the quorum to accept this, but as I see the overall idea is accepted, and we agree to have a spec to see the details 14:59:29 if I were to redefine API from scratch, AAP would probably not exist at all, instead rolling it into SG API, but it does exist and it's not make believe world, so we have to keep both 14:59:33 ok I can write a spec next week 14:59:56 ihrachys: thanks 15:00:07 +1 for spec and for voting on it next week when we will have quorum 15:00:10 +1 to the idea (I need the spec to check the implementation) 15:00:23 in general I am +1 to the idea to disable anti-spoof check for MAC too (and it would be a good chance to clarify the current behavior/assumption as ihar raised first) 15:00:29 or if we will not have quorum, to discuss it in details during ptg :) 15:00:43 slaweq: +1 15:01:05 I just wanted to mention that the week after w have PTG, and can have more discussion :-) 15:01:09 it's ok to discuss in spec and if there's agreement then you guys can vote or whatever the process is. 15:01:21 ++ 15:01:39 thanks for consideration 15:01:48 ok, I think we can't do more today, thanks everybody for participating and sharing ideas 15:01:59 o/ 15:02:08 have a nice weekend 15:02:12 thanks all. have a good weekend 15:02:24 have a great weekend 15:02:24 Have a nice weekend, bye 15:02:29 #endmeeting 15:24:34 Merged openstack/neutron stable/xena: Fix "_sync_metadata_ports" with no DHCP subnets https://review.opendev.org/c/openstack/neutron/+/812334 15:35:10 Rodolfo Alonso proposed openstack/neutron stable/victoria: [DVR] Check if SNAT iptables manager is initialized https://review.opendev.org/c/openstack/neutron/+/813205 15:35:43 Rodolfo Alonso proposed openstack/neutron stable/ussuri: [DVR] Check if SNAT iptables manager is initialized https://review.opendev.org/c/openstack/neutron/+/813206 15:36:02 Rodolfo Alonso proposed openstack/neutron stable/train: [DVR] Check if SNAT iptables manager is initialized https://review.opendev.org/c/openstack/neutron/+/813207 15:36:07 Daniel Alvarez proposed openstack/neutron master: [ovn] Clean up MAC_Binding entries with ovsdb-client https://review.opendev.org/c/openstack/neutron/+/812805 15:45:47 hello, how can I trigger rescheduling of L3 and DHCP agents of a router ? 16:05:58 Rodolfo Alonso proposed openstack/os-ken master: nx_action_encap and nx_action_decap classes are defined https://review.opendev.org/c/openstack/os-ken/+/813214 16:08:26 Rodolfo Alonso proposed openstack/os-ken master: Add support for revised RFC8227 withdraw labels https://review.opendev.org/c/openstack/os-ken/+/813215 16:09:32 Rodolfo Alonso proposed openstack/os-ken master: Update bridge.py https://review.opendev.org/c/openstack/os-ken/+/813216 16:14:32 Rodolfo Alonso proposed openstack/os-ken master: updated jsonrpc.Session call to have correct arguments for latest version of ovs https://review.opendev.org/c/openstack/os-ken/+/813217 16:56:07 Daniel Speichert proposed openstack/neutron master: Fixes OVN driver validating Geneve max_header_size https://review.opendev.org/c/openstack/neutron/+/813230 17:17:23 Daniel Speichert proposed openstack/neutron master: Fix OVN driver validating Geneve max_header_size https://review.opendev.org/c/openstack/neutron/+/813230 17:17:25 Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: Use Ubuntu minimal image as advanced guest image https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/813195 17:19:26 Rodolfo Alonso proposed openstack/neutron master: [WIP][OVN] Sync QoS policies https://review.opendev.org/c/openstack/neutron/+/813052 17:34:13 Slawek Kaplonski proposed openstack/neutron master: [OVN Migration] Remove qr and dhcp ports from the nodes https://review.opendev.org/c/openstack/neutron/+/813186 17:34:13 Slawek Kaplonski proposed openstack/neutron master: [OVN Migration] Remove trunk's subports from the nodes https://review.opendev.org/c/openstack/neutron/+/813187 17:43:37 Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Use Ubuntu minimal image as advanced guest image https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/813195 17:57:16 Elvira García Ruiz proposed openstack/neutron master: [ovn] Add logs for ovs to ovn migration https://review.opendev.org/c/openstack/neutron/+/813237 18:17:34 Elvira García Ruiz proposed openstack/neutron master: [ovn] Add logs for ovs to ovn migration https://review.opendev.org/c/openstack/neutron/+/813237 00:14:54 Merged openstack/neutron master: [ovn] Add logs for ovs to ovn migration https://review.opendev.org/c/openstack/neutron/+/813237 03:18:55 Shawn.Lu proposed openstack/neutron stable/wallaby: Do not subscribe segment when segmetn plugin disabled https://review.opendev.org/c/openstack/neutron/+/805788 03:29:03 Shawn.Lu proposed openstack/neutron master: Do not subscribe segment when segmetn plugin disabled https://review.opendev.org/c/openstack/neutron/+/813272 06:17:17 Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Use Ubuntu minimal image as advanced guest image https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/813195 15:54:46 Slawek Kaplonski proposed openstack/neutron-lib master: [Doc] Update callbacks guide https://review.opendev.org/c/openstack/neutron-lib/+/813287 11:52:23 Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Use Ubuntu minimal image as advanced guest image https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/813195 14:47:24 Maxim Babushkin proposed openstack/networking-ovn stable/train: Add "FLAVOR_NAME" to ovn migration resources creation https://review.opendev.org/c/openstack/networking-ovn/+/813298 19:40:41 Daniel Alvarez proposed openstack/neutron master: [ovn] Clean up MAC_Binding entries with ovsdb-client https://review.opendev.org/c/openstack/neutron/+/812805 20:13:57 Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Use Ubuntu minimal image as advanced guest image https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/813195 05:49:53 huahai proposed openstack/neutron stable/wallaby: [ovn]Update get datapath id to network from Port_Binding https://review.opendev.org/c/openstack/neutron/+/813376 07:03:07 Lajos Katona proposed openstack/neutron master: BFD for Neutron, server side https://review.opendev.org/c/openstack/neutron/+/808046 07:09:15 Bhagyashri Shewale proposed openstack/networking-bgpvpn stable/xena: Run TripleO jobs on CentOS8 instead of CentOS7 https://review.opendev.org/c/openstack/networking-bgpvpn/+/809500 07:09:35 Bhagyashri Shewale proposed openstack/networking-bgpvpn stable/wallaby: Run TripleO jobs on CentOS8 instead of CentOS7 https://review.opendev.org/c/openstack/networking-bgpvpn/+/809501 07:09:41 Bhagyashri Shewale proposed openstack/networking-bgpvpn stable/victoria: Run TripleO jobs on CentOS8 instead of CentOS7 https://review.opendev.org/c/openstack/networking-bgpvpn/+/809502 07:09:47 Bhagyashri Shewale proposed openstack/networking-bgpvpn stable/ussuri: Run TripleO jobs on CentOS8 instead of CentOS7 https://review.opendev.org/c/openstack/networking-bgpvpn/+/809503 07:09:55 Bhagyashri Shewale proposed openstack/networking-bgpvpn stable/train: Run TripleO jobs on CentOS8 instead of CentOS7 https://review.opendev.org/c/openstack/networking-bgpvpn/+/809504 07:59:19 Daniel Alvarez proposed openstack/neutron master: [ovn] Clean up MAC_Binding entries with ovsdb-client https://review.opendev.org/c/openstack/neutron/+/812805 09:09:39 Slawek Kaplonski proposed openstack/neutron-vpnaas master: Drop install_venv https://review.opendev.org/c/openstack/neutron-vpnaas/+/809912 09:12:58 Slawek Kaplonski proposed openstack/neutron-lib master: Rehome ``QuotaDriverAPI`` class https://review.opendev.org/c/openstack/neutron-lib/+/811975 09:20:37 slaweq, https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/813195 09:20:46 I pushed a new patch last week 09:20:51 because CI was failing 09:21:49 I see now you updated it with new tools and a new flavor 09:23:25 ralonsoh: yes, I was checking it during the weekend 09:23:28 it's now almost ok 09:23:37 OVN job is failing 09:23:38 I need to check what's missing in that one test in ovn job 09:23:42 I'm checking it 09:23:44 the same test in all releases 09:24:00 yep, that's why I hope I will easy reproduce it locally 09:24:14 I'm deploying devstack with same ubuntu minimal image to check that test 09:24:23 but in overall it looks promising 09:24:28 all other tests are fine now 09:24:38 and they run with flavor with only 256 MB or memory 09:24:45 so should be a bit better IMO :) 09:25:10 for sure! 09:51:58 Merged openstack/networking-bgpvpn stable/xena: Run TripleO jobs on CentOS8 instead of CentOS7 https://review.opendev.org/c/openstack/networking-bgpvpn/+/809500 10:22:40 lucasagomes, slaweq https://review.opendev.org/c/openstack/networking-ovn/+/813145 10:22:46 if you don't mind 10:22:48 easy one 10:22:53 Merged openstack/networking-bgpvpn stable/wallaby: Run TripleO jobs on CentOS8 instead of CentOS7 https://review.opendev.org/c/openstack/networking-bgpvpn/+/809501 10:24:14 ralonsoh, on it o/ 10:26:05 Rodolfo Alonso proposed openstack/neutron stable/xena: [OVN] Update the DHCP options when the metadata port is modified https://review.opendev.org/c/openstack/neutron/+/813408 10:26:33 Merged openstack/neutron stable/ussuri: [DVR] Check if SNAT iptables manager is initialized https://review.opendev.org/c/openstack/neutron/+/813206 10:29:08 ralonsoh++ thanks for fixing that! 10:29:13 yw 10:31:20 Rodolfo Alonso proposed openstack/neutron stable/wallaby: [OVN] Update the DHCP options when the metadata port is modified https://review.opendev.org/c/openstack/neutron/+/813409 10:31:53 ralonsoh: +W'ed 10:31:58 thanks! 10:32:29 Rodolfo Alonso proposed openstack/neutron stable/victoria: [OVN] Update the DHCP options when the metadata port is modified https://review.opendev.org/c/openstack/neutron/+/813410 10:33:45 Manu B proposed openstack/neutron-dynamic-routing master: Updating status, name field and handling reboot operation https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/811300 10:40:41 Rodolfo Alonso proposed openstack/neutron stable/ussuri: [OVN] Update the DHCP options when the metadata port is modified https://review.opendev.org/c/openstack/neutron/+/813411 10:56:15 Merged openstack/neutron stable/train: [DVR] Check if SNAT iptables manager is initialized https://review.opendev.org/c/openstack/neutron/+/813207 10:56:20 Merged openstack/neutron master: Fix OVN driver validating Geneve max_header_size https://review.opendev.org/c/openstack/neutron/+/813230 11:01:57 huanghailun proposed openstack/neutron stable/wallaby: [ovn]Update get datapath id to network from Port_Binding https://review.opendev.org/c/openstack/neutron/+/813376 11:13:48 Slawek Kaplonski proposed openstack/neutron master: Deprecate 'allow_overlapping_ips' config option https://review.opendev.org/c/openstack/neutron/+/807848 11:20:58 Merged openstack/neutron-lib stable/xena: Dropping lower constraints testing (stable Xena) https://review.opendev.org/c/openstack/neutron-lib/+/808599 11:21:29 Manu B proposed openstack/python-neutronclient master: Add neutron and osc commands for bgp speaker router associationw https://review.opendev.org/c/openstack/python-neutronclient/+/803318 11:27:15 Edward Hope-Morley proposed openstack/neutron master: Revert "ovs firewall: fix mac learning on the ingress rule table when ovs offload enabled" https://review.opendev.org/c/openstack/neutron/+/813415 11:33:56 Merged openstack/neutron stable/train: [Functional] Wait for the initial state of ha router before test https://review.opendev.org/c/openstack/neutron/+/808500 11:42:48 Manu B proposed openstack/python-neutronclient master: Add neutron and osc commands for bgp speaker peer association https://review.opendev.org/c/openstack/python-neutronclient/+/803458 13:05:09 Kamil Sambor proposed openstack/networking-ovn stable/train: ovn: Do not set reside-on-redirect-chassis on distributed FIP https://review.opendev.org/c/openstack/networking-ovn/+/811890 13:08:56 Merged openstack/neutron stable/victoria: [DVR] Check if SNAT iptables manager is initialized https://review.opendev.org/c/openstack/neutron/+/813205 13:30:43 Przemyslaw Szczerbik proposed openstack/neutron master: Report CUSTOM_VNIC_TYPE_ traits on Neutron agent RP https://review.opendev.org/c/openstack/neutron/+/800445 13:30:43 Przemyslaw Szczerbik proposed openstack/neutron master: Report pkt processing capacity on Neutron agent RP https://review.opendev.org/c/openstack/neutron/+/800446 13:30:44 Przemyslaw Szczerbik proposed openstack/neutron master: Add port-resource-request-groups extension https://review.opendev.org/c/openstack/neutron/+/805637 13:30:44 Przemyslaw Szczerbik proposed openstack/neutron master: Sanitize profile column of ml2_port_bindings table in the DB https://review.opendev.org/c/openstack/neutron/+/811411 13:32:54 Przemyslaw Szczerbik proposed openstack/neutron master: Enable QoS minimum packet rate rule for OVS backend https://review.opendev.org/c/openstack/neutron/+/805391 15:12:11 Elvira García Ruiz proposed openstack/neutron stable/wallaby: [OVN] Allow IP allocation with different segments for OVN service ports https://review.opendev.org/c/openstack/neutron/+/813447 15:17:42 Elvira García Ruiz proposed openstack/neutron stable/xena: [OVN] Allow IP allocation with different segments for OVN service ports https://review.opendev.org/c/openstack/neutron/+/813448 15:34:47 Elvira García Ruiz proposed openstack/neutron stable/victoria: [OVN] Allow IP allocation with different segments for OVN service ports https://review.opendev.org/c/openstack/neutron/+/813450 15:47:10 Lajos Katona proposed openstack/neutron master: CI: add experimental jobs to be executed with n-lib master https://review.opendev.org/c/openstack/neutron/+/807722 15:49:41 Lajos Katona proposed openstack/neutron master: Add functional tests for ECMP routes https://review.opendev.org/c/openstack/neutron/+/805052 15:52:21 Lajos Katona proposed openstack/neutron-tempest-plugin master: WIP: API tests for BFD support https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/800949 15:54:47 Elvira García Ruiz proposed openstack/neutron stable/ussuri: [OVN] Allow IP allocation with different segments for OVN service ports https://review.opendev.org/c/openstack/neutron/+/813454 15:56:02 bcafarel, one qq 15:56:06 https://review.opendev.org/c/openstack/neutron/+/813376 15:56:15 this is only for U, V and W 15:56:18 and n-ovn T 15:56:28 what should the commit message have? 15:56:35 stable-only? 15:58:10 ralonsoh: something like that yes, no strict rule except make our lives easier - so "[stable only]" and explain in commit message why xena is good there 15:58:24 perfect and thanks 16:01:01 lucasagomes, please check https://review.opendev.org/c/openstack/neutron/+/813376 16:01:50 upsss just for 3 seconds 16:24:02 Lajos Katona proposed openstack/ovsdbapp stable/xena: tools: run functional tests against ovn/main branch https://review.opendev.org/c/openstack/ovsdbapp/+/813342 16:24:20 Lajos Katona proposed openstack/ovsdbapp stable/xena: Update .gitreview for stable/xena https://review.opendev.org/c/openstack/ovsdbapp/+/808269 16:24:28 Lajos Katona proposed openstack/ovsdbapp stable/xena: Update TOX_CONSTRAINTS_FILE for stable/xena https://review.opendev.org/c/openstack/ovsdbapp/+/808273 16:26:25 Elvira García Ruiz proposed openstack/neutron stable/train: [OVN] Allow IP allocation with different segments for OVN service ports https://review.opendev.org/c/openstack/neutron/+/813457 16:26:32 Merged openstack/ovsdbapp master: tools: run functional tests against ovn/main branch https://review.opendev.org/c/openstack/ovsdbapp/+/812985 16:35:03 Rodolfo Alonso proposed openstack/neutron master: Remove "get_logical_port_chassis_and_datapath" https://review.opendev.org/c/openstack/neutron/+/813462 18:14:57 Merged openstack/neutron master: [HA] Do not add initial state change delay in HA router https://review.opendev.org/c/openstack/neutron/+/811751 18:45:31 Merged openstack/ovsdbapp master: ic: add support for OVN_IC_Northbound schema https://review.opendev.org/c/openstack/ovsdbapp/+/809151 19:20:16 Merged openstack/ovsdbapp master: nb: fix route.output_port name https://review.opendev.org/c/openstack/ovsdbapp/+/807749 19:53:17 Daniel Alvarez proposed openstack/neutron master: [ovn] Clean up MAC_Binding entries with ovsdb-client https://review.opendev.org/c/openstack/neutron/+/812805 20:04:06 Merged openstack/neutron master: Rename OVN's "master" branch to "main" https://review.opendev.org/c/openstack/neutron/+/812674 20:07:51 Daniel Speichert proposed openstack/neutron stable/xena: Fix OVN driver validating Geneve max_header_size https://review.opendev.org/c/openstack/neutron/+/813346 20:07:59 Daniel Alvarez proposed openstack/neutron master: [ovn] Stop monitoring the SB MAC_Binding table to reduce mem footprint https://review.opendev.org/c/openstack/neutron/+/812805 20:31:14 Daniel Alvarez proposed openstack/neutron master: [ovn] Stop monitoring the SB MAC_Binding table to reduce mem footprint https://review.opendev.org/c/openstack/neutron/+/812805 21:52:55 Daniel Alvarez proposed openstack/neutron master: [ovn] Stop monitoring the SB MAC_Binding table to reduce mem footprint https://review.opendev.org/c/openstack/neutron/+/812805 01:44:02 huanghailun proposed openstack/neutron stable/wallaby: [stable only][ovn]Update get datapath id to network from Port_Binding https://review.opendev.org/c/openstack/neutron/+/813376 01:57:02 Merged openstack/networking-ovn stable/train: OVN git repository default branch is called "main" https://review.opendev.org/c/openstack/networking-ovn/+/813145 05:10:05 Manu B proposed openstack/neutron-lib master: Addition of status and name field to bgp_associations API https://review.opendev.org/c/openstack/neutron-lib/+/813557 07:01:04 Hi, any using neutron with OVN? 07:02:21 i have a trouble with OVN DB 07:02:35 ovn-northd log error {"details":"inconsistent data","error":"ovsdb error"} 07:16:47 #openvswitch 07:44:45 Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Use Ubuntu minimal image as advanced guest image https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/813195 08:11:47 Kamil Sambor proposed openstack/networking-ovn stable/train: ovn: Do not set reside-on-redirect-chassis on distributed FIP https://review.opendev.org/c/openstack/networking-ovn/+/811890 09:20:34 lajoskatona: hi, can You take a look at https://review.opendev.org/c/openstack/neutron-lib/+/811708 when You will have some time? thx in advance 09:21:22 lajoskatona: and also https://review.opendev.org/c/openstack/neutron/+/812658 if You'll have few minutes :) 09:21:25 slaweq: sure, checking 09:21:29 thx a lot 09:39:04 huanghailun proposed openstack/neutron master: [ovn]Get network availability_zones from Logical_Switch https://review.opendev.org/c/openstack/neutron/+/813599 09:49:24 Lajos Katona proposed openstack/neutron-lib master: BFD validator https://review.opendev.org/c/openstack/neutron-lib/+/809978 10:09:25 Merged openstack/neutron-lib master: Rehome ``QuotaDriverAPI`` class https://review.opendev.org/c/openstack/neutron-lib/+/811975 10:13:22 liuyulong proposed openstack/neutron-specs master: Spec for distributed datapath for metadata https://review.opendev.org/c/openstack/neutron-specs/+/802854 10:58:44 Merged openstack/neutron master: [Policy] Set scope_types for BaseCheck rules https://review.opendev.org/c/openstack/neutron/+/807559 11:22:06 Lucas Alvares Gomes proposed openstack/neutron master: Allow setting always_learn_from_arp_request for routers https://review.opendev.org/c/openstack/neutron/+/813610 11:27:54 Lucas Alvares Gomes proposed openstack/neutron master: [OVN] Allow setting always_learn_from_arp_request for routers https://review.opendev.org/c/openstack/neutron/+/813610 12:22:19 Merged openstack/neutron master: [OVN] Update the DHCP options when the metadata port is modified https://review.opendev.org/c/openstack/neutron/+/807692 12:24:56 Slawek Kaplonski proposed openstack/neutron master: Use ovs constants from neutron-lib https://review.opendev.org/c/openstack/neutron/+/797120 12:29:06 Slawek Kaplonski proposed openstack/neutron master: Remove ovs agent's common constants module https://review.opendev.org/c/openstack/neutron/+/797121 12:29:50 Merged openstack/neutron stable/xena: Fix OVN driver validating Geneve max_header_size https://review.opendev.org/c/openstack/neutron/+/813346 12:29:54 Merged openstack/neutron stable/queens: Remove dhcp_extra_opt name after first newline character https://review.opendev.org/c/openstack/neutron/+/810880 12:32:02 lajoskatona: if You will have some time, please check again https://review.opendev.org/c/openstack/neutron/+/797120, https://review.opendev.org/c/openstack/neutron/+/797121 and https://review.opendev.org/c/openstack/neutron-lib/+/807224 12:32:18 slaweq: ack 12:32:22 thx a lot 12:33:41 Anton Vazhnetsov proposed openstack/ovsdbapp master: nb: set chassis_name for new gateway chassis https://review.opendev.org/c/openstack/ovsdbapp/+/813622 12:45:06 Lucas Alvares Gomes proposed openstack/neutron master: [OVN] Allow setting always_learn_from_arp_request for routers https://review.opendev.org/c/openstack/neutron/+/813610 12:47:26 Lucas Alvares Gomes proposed openstack/neutron master: [OVN] Allow setting always_learn_from_arp_request for routers https://review.opendev.org/c/openstack/neutron/+/813610 12:48:52 Slawek Kaplonski proposed openstack/neutron stable/ussuri: HA-non-DVR router don't need manually add static route https://review.opendev.org/c/openstack/neutron/+/792876 13:08:01 Anton Vazhnetsov proposed openstack/ovsdbapp master: nb: set chassis_name for new gateway chassis https://review.opendev.org/c/openstack/ovsdbapp/+/813622 13:23:06 Przemyslaw Szczerbik proposed openstack/neutron-lib master: Add binding-profile.allocation converter https://review.opendev.org/c/openstack/neutron-lib/+/813650 13:48:37 Przemyslaw Szczerbik proposed openstack/neutron master: Sanitize profile column of ml2_port_bindings table in the DB https://review.opendev.org/c/openstack/neutron/+/811411 13:49:10 Przemyslaw Szczerbik proposed openstack/neutron master: Enable QoS minimum packet rate rule for OVS backend https://review.opendev.org/c/openstack/neutron/+/805391 14:00:23 lajoskatona: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 14:00:36 hi 14:00:48 you forgot to close tre previous meeting 14:00:54 hm.... 14:00:55 that previous meeting must have been a long-running one :) 14:00:59 :) 14:01:02 #endmeeting