14:14:34 <lajoskatona2> #startmeeting neutron_drivers
14:14:34 <opendevmeet> 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 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:14:34 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:14:44 <lajoskatona2> Hi, sorry for being late....
14:14:54 <slaweq> hi
14:14:58 <ralonsoh> hi
14:15:05 <Gues__________________________> o/
14:15:26 <slaweq> LOL ihrachys nice new nick :P
14:15:31 <slaweq> pretty long one
14:15:35 <ihrachys> yeah. first time connected to this server
14:15:44 <lajoskatona2> not sure if we will have quorum, as mlavalle can't join today
14:17:07 <lajoskatona2> The topic for today: https://bugs.launchpad.net/neutron/+bug/1946251
14:18:07 <amotoki> hi
14:18:18 <lajoskatona2> Hi amotoki
14:19:17 <slaweq> for that rfe I think we would need some "historical" background why it was such coupled always :)
14:20:15 <slaweq> personally I don't see any issues with allowing to disable anti-spoofing and still have SG on the port
14:20:32 <slaweq> but maybe there were good reasons for that in the past :)
14:20:50 <ihrachys> 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 <ihrachys> so we can only assume, based on historical observations, that it disables both SG and anti-spoof
14:23:22 <slaweq> 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 <slaweq> so it's done on purpose I would say
14:24:06 <ihrachys> clearly on purpose, so should be documented (in addition to explaining the intent of the API)
14:24:23 <slaweq> I agree that this should be documented :)
14:24:38 <amotoki> yeah, agree. it sould be documented
14:24:41 <ihrachys> 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 <ihrachys> with SGs, it's possible by having a promiscuous SG
14:25:02 <slaweq> 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 <slaweq> something like that is already possible for ip_address
14:25:19 <slaweq> as You can set 0.0.0.0 there
14:25:25 <opendevreview> 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 <amotoki> MAC=ANY may confuse L2 switches though
14:25:59 <ihrachys> that would be up to driver to interpret it (and declare support for this extension)
14:26:09 <amotoki> but perhaps it would be a responsibility of who use it
14:26:41 <ihrachys> alternatively, a new field could be added (port_spoofing_enabled=false)
14:26:56 <ihrachys> I mean, anti*
14:27:03 <slaweq> ihrachys: then we should also change logic for "port_security_enabled" field
14:27:12 <slaweq> to not be dependen on allowed_address_pairs anymore
14:27:13 <slaweq> right?
14:27:14 <ihrachys> but first, let's maybe discuss if you believe the API is needed at all
14:27:15 <ihrachys> ?
14:27:37 <ihrachys> slaweq no why? we would keep original behavior, no?
14:28:20 <ihrachys> 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 <ralonsoh> why should we change this behaviour?
14:29:01 <slaweq> ihrachys: I'm not sure - just thinking
14:29:15 <amotoki> 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 <slaweq> how this new attribute port_antispoofing_enabled=false would work if we would have allowed_address_pairs for example?
14:30:02 <slaweq> 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 <ihrachys> 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 <ihrachys> 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 <ralonsoh> Why adding a new extension if we have "port_security_enabled"?
14:31:36 <slaweq> IMHO the easiest way would be to add possibility of MAC=ANY in allowed_address_pairs to do that
14:31:41 <ihrachys> ralonsoh because it disables both ACLs and anti-spoofing (apparently)
14:31:56 <ihrachys> and some may want to have SG but not the other
14:32:09 <ralonsoh> not ACLs, but I'll need to check that
14:32:23 <ihrachys> SGs are verbotten with port_sec=false
14:32:31 <ihrachys> checked on POST
14:33:45 <lajoskatona> I found this old bug where the discussion can be interesting: https://bugs.launchpad.net/neutron/+bug/1453667
14:33:59 <slaweq> yes, currently SGs and allowed_address_pair are possible only when port_security_enabled = True
14:35:32 <ihrachys> 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 <ihrachys> *for
14:36:16 <ihrachys> but I assume port_sec=false == (SG=off AND anti-spoofing=off) as per code and historical observations
14:36:25 <ihrachys> so just doc update needed there
14:36:42 <slaweq> that's correct currently IMO
14:36:51 <lajoskatona> 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 <slaweq> 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 <lajoskatona> but otherwise I can't see why we cant decouple the 2, allowed-address -pairs and sec-groups
14:37:38 <slaweq> and port_Security would be related only to SGs
14:37:44 <ihrachys> 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 <slaweq> or am I misunderstanding it?
14:38:12 <ihrachys> slaweq no you can't change behavior for existing API
14:38:15 <lajoskatona> slaweq: yeah that's my understanding
14:38:21 <ihrachys> so port_sec would still do what it does now - disable both
14:38:35 <ralonsoh> right, we can't change current API
14:38:44 <lajoskatona> and if I understand well the MAC=any or multimac is another feature,
14:38:46 <amotoki> ihrachys: yeah, IIRC more (IP, MAC) pair is allowed and it is expected
14:38:48 <ralonsoh> but we can add the anti-spoofing API
14:39:35 <slaweq> 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 <ihrachys> 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 <slaweq> and IMO we should simly allow to set ANY MAC in the AAP field
14:40:19 <slaweq> as we already allow for IP addresses there
14:40:33 <slaweq> and by that kind of "bypass" antispoofing protection for port
14:40:36 <lajoskatona> slaweq: +1
14:40:45 <ihrachys> slaweq it sucks I admit. yes, overloading seems like a more clean way of doing it but I may be wrong.
14:41:08 <ralonsoh> but that will require support from each specific backend FW
14:41:18 <ihrachys> note for IPs we do masks, where /0 means ANY
14:41:26 <ralonsoh> I don't know if this is possible in OVS FW or iptables or OVN
14:41:27 <ihrachys> for MACs, I guess masks are useless, or?
14:41:33 <opendevreview> 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 <dalvarez> lucasagomes: ^
14:41:56 <dalvarez> 75 GB down to 7GB \o/
14:42:01 <slaweq> ihrachys: You're right
14:42:01 <ihrachys> ralonsoh can
14:42:08 <lucasagomes> dalvarez, ohh yeah
14:43:40 <ihrachys> 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 <amotoki> what do you mean by ANY AAP? Any IP or Any MAC?
14:44:30 <ihrachys> ANY MAC AAP
14:44:48 <ihrachys> (I am not shouting, it's acronym soup)
14:44:55 <ralonsoh> to be honest, I need to see the implementation. But of course, it worths to go this direction
14:45:05 <slaweq> ihrachys: for ANY IP address in AAP agent will add /0 IP into ipset or OF rules in br-int
14:45:23 <slaweq> to allow egress traffic with IPs from that CIDR from this port
14:46:12 <slaweq> I don't know how hard it may be to do the same for "ANY" MACs eg. in ovs case
14:46:38 <ralonsoh> in OVS we can disable "provides_arp_spoofing_protection" in the FW
14:46:49 <ralonsoh> well, for all of them, never mind
14:46:58 <ihrachys> 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 <lajoskatona> 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 <ralonsoh> yes, that's what I understand
14:47:59 <slaweq> 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 <ihrachys> 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 <slaweq> that would disable it completly, no?
14:48:31 <amotoki> I am a bit confused. why do we need to downe AAP if ANY MAC is specified?
14:48:32 <ralonsoh> ihrachys, I need to check that in iptables and OVS FW
14:48:53 <amotoki> s/downe/down/
14:48:56 <ihrachys> lajoskatona that's my understanding, yes
14:49:53 <ihrachys> 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 <ihrachys> if it's a flag like port_security, it's the former
14:50:41 <ihrachys> 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 <lajoskatona> if a flag like thing than I would make it simpler like allowed_address_pairs=False or similar
14:51:23 <ihrachys> what do you mean "simpler"
14:51:56 <amotoki> 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 <lajoskatona> 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 <ihrachys> 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 <lajoskatona> yeah for that the API would be changed to allow list or bool, that's true
14:53:23 <slaweq> I don't think it's good idea to accept 2 types as the allowed_address_pairs
14:54:08 <ihrachys> list or bool sounds like not the best API
14:54:24 <slaweq> ihrachys++
14:54:46 <lajoskatona> ok, than it's not a simple flag, we have to always fill the whole ip=...mac=.... fields
14:55:16 <slaweq> 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 <ihrachys> 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 <lajoskatona> do we need a spec for it to see more details written?
14:56:21 <slaweq> 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 <ihrachys> 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 <ihrachys> slaweq yes, that would kill all checks
14:57:06 <slaweq> lajoskatona: +1 for spec with short description of various possible solutions for that
14:57:14 <amotoki> why IP address check needs to be disabled? IP of AAP is also used in remote group in SG API
14:57:34 <ihrachys> 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 <lajoskatona> 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 <ihrachys> 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 <ihrachys> ok I can write a spec next week
14:59:56 <lajoskatona> ihrachys: thanks
15:00:07 <slaweq> +1 for spec and for voting on it next week when we will have quorum
15:00:10 <ralonsoh> +1 to the idea (I need the spec to check the implementation)
15:00:23 <amotoki> 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 <slaweq> or if we will not have quorum, to discuss it in details during ptg :)
15:00:43 <lajoskatona> slaweq: +1
15:01:05 <lajoskatona> I  just wanted to mention that the week after w have PTG, and can have more discussion :-)
15:01:09 <ihrachys> 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 <slaweq> ++
15:01:39 <ihrachys> thanks for consideration
15:01:48 <lajoskatona> ok, I think we can't do more today, thanks everybody for participating and sharing ideas
15:01:59 <slaweq> o/
15:02:08 <ralonsoh> have a nice weekend
15:02:12 <amotoki> thanks all. have a good weekend
15:02:24 <slaweq> have a great weekend
15:02:24 <lajoskatona> Have a nice weekend, bye
15:02:29 <lajoskatona> #endmeeting
15:24:34 <opendevreview> Merged openstack/neutron stable/xena: Fix "_sync_metadata_ports" with no DHCP subnets  https://review.opendev.org/c/openstack/neutron/+/812334
15:35:10 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <mloza> hello, how can I trigger rescheduling of L3 and DHCP agents of a router ?
16:05:58 <opendevreview> 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 <opendevreview> 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 <opendevreview> Rodolfo Alonso proposed openstack/os-ken master: Update bridge.py  https://review.opendev.org/c/openstack/os-ken/+/813216
16:14:32 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> Rodolfo Alonso proposed openstack/neutron master: [WIP][OVN] Sync QoS policies  https://review.opendev.org/c/openstack/neutron/+/813052
17:34:13 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> Merged openstack/neutron master: [ovn] Add logs for ovs to ovn migration  https://review.opendev.org/c/openstack/neutron/+/813237
03:18:55 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> Slawek Kaplonski proposed openstack/neutron-lib master: [Doc] Update callbacks guide  https://review.opendev.org/c/openstack/neutron-lib/+/813287
11:52:23 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> Lajos Katona proposed openstack/neutron master: BFD for Neutron, server side  https://review.opendev.org/c/openstack/neutron/+/808046
07:09:15 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> Slawek Kaplonski proposed openstack/neutron-vpnaas master: Drop install_venv  https://review.opendev.org/c/openstack/neutron-vpnaas/+/809912
09:12:58 <opendevreview> Slawek Kaplonski proposed openstack/neutron-lib master: Rehome ``QuotaDriverAPI`` class  https://review.opendev.org/c/openstack/neutron-lib/+/811975
09:20:37 <ralonsoh> slaweq, https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/813195
09:20:46 <ralonsoh> I pushed a new patch last week
09:20:51 <ralonsoh> because CI was failing
09:21:49 <ralonsoh> I see now you updated it with new tools and a new flavor
09:23:25 <slaweq> ralonsoh: yes, I was checking it during the weekend
09:23:28 <slaweq> it's now almost ok
09:23:37 <ralonsoh> OVN job is failing
09:23:38 <slaweq> I need to check what's missing in that one test in ovn job
09:23:42 <slaweq> I'm checking it
09:23:44 <ralonsoh> the same test in all releases
09:24:00 <slaweq> yep, that's why I hope I will easy reproduce it locally
09:24:14 <slaweq> I'm deploying devstack with same ubuntu minimal image to check that test
09:24:23 <slaweq> but in overall it looks promising
09:24:28 <slaweq> all other tests are fine now
09:24:38 <slaweq> and they run with flavor with only 256 MB or memory
09:24:45 <slaweq> so should be a bit better IMO :)
09:25:10 <ralonsoh> for sure!
09:51:58 <opendevreview> 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 <ralonsoh> lucasagomes, slaweq https://review.opendev.org/c/openstack/networking-ovn/+/813145
10:22:46 <ralonsoh> if you don't mind
10:22:48 <ralonsoh> easy one
10:22:53 <opendevreview> 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 <lucasagomes> ralonsoh, on it o/
10:26:05 <opendevreview> 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 <opendevreview> Merged openstack/neutron stable/ussuri: [DVR] Check if SNAT iptables manager is initialized  https://review.opendev.org/c/openstack/neutron/+/813206
10:29:08 <lucasagomes> ralonsoh++ thanks for fixing that!
10:29:13 <ralonsoh> yw
10:31:20 <opendevreview> 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 <slaweq> ralonsoh: +W'ed
10:31:58 <ralonsoh> thanks!
10:32:29 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> Merged openstack/neutron stable/train: [DVR] Check if SNAT iptables manager is initialized  https://review.opendev.org/c/openstack/neutron/+/813207
10:56:20 <opendevreview> Merged openstack/neutron master: Fix OVN driver validating Geneve max_header_size  https://review.opendev.org/c/openstack/neutron/+/813230
11:01:57 <opendevreview> 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 <opendevreview> Slawek Kaplonski proposed openstack/neutron master: Deprecate 'allow_overlapping_ips' config option  https://review.opendev.org/c/openstack/neutron/+/807848
11:20:58 <opendevreview> Merged openstack/neutron-lib stable/xena: Dropping lower constraints testing (stable Xena)  https://review.opendev.org/c/openstack/neutron-lib/+/808599
11:21:29 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> Merged openstack/neutron stable/victoria: [DVR] Check if SNAT iptables manager is initialized  https://review.opendev.org/c/openstack/neutron/+/813205
13:30:43 <opendevreview> 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 <opendevreview> 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 <opendevreview> Przemyslaw Szczerbik proposed openstack/neutron master: Add port-resource-request-groups extension  https://review.opendev.org/c/openstack/neutron/+/805637
13:30:44 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> Lajos Katona proposed openstack/neutron master: Add functional tests for ECMP routes  https://review.opendev.org/c/openstack/neutron/+/805052
15:52:21 <opendevreview> 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 <opendevreview> 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 <ralonsoh> bcafarel, one qq
15:56:06 <ralonsoh> https://review.opendev.org/c/openstack/neutron/+/813376
15:56:15 <ralonsoh> this is only for U, V and W
15:56:18 <ralonsoh> and n-ovn T
15:56:28 <ralonsoh> what should the commit message have?
15:56:35 <ralonsoh> stable-only?
15:58:10 <bcafarel> 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 <ralonsoh> perfect and thanks
16:01:01 <ralonsoh> lucasagomes, please check https://review.opendev.org/c/openstack/neutron/+/813376
16:01:50 <ralonsoh> upsss just for 3 seconds
16:24:02 <opendevreview> 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 <opendevreview> Lajos Katona proposed openstack/ovsdbapp stable/xena: Update .gitreview for stable/xena  https://review.opendev.org/c/openstack/ovsdbapp/+/808269
16:24:28 <opendevreview> 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 <opendevreview> 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 <opendevreview> Merged openstack/ovsdbapp master: tools: run functional tests against ovn/main branch  https://review.opendev.org/c/openstack/ovsdbapp/+/812985
16:35:03 <opendevreview> Rodolfo Alonso proposed openstack/neutron master: Remove "get_logical_port_chassis_and_datapath"  https://review.opendev.org/c/openstack/neutron/+/813462
18:14:57 <opendevreview> 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 <opendevreview> Merged openstack/ovsdbapp master: ic: add support for OVN_IC_Northbound schema  https://review.opendev.org/c/openstack/ovsdbapp/+/809151
19:20:16 <opendevreview> Merged openstack/ovsdbapp master: nb: fix route.output_port name  https://review.opendev.org/c/openstack/ovsdbapp/+/807749
19:53:17 <opendevreview> 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 <opendevreview> Merged openstack/neutron master: Rename OVN's "master" branch to "main"  https://review.opendev.org/c/openstack/neutron/+/812674
20:07:51 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <chungphan> Hi, any using neutron with OVN?
07:02:21 <chungphan> i have a trouble with OVN DB
07:02:35 <chungphan> ovn-northd log error {"details":"inconsistent data","error":"ovsdb error"}
07:16:47 <chungphan> #openvswitch
07:44:45 <opendevreview> 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 <opendevreview> 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 <slaweq> 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 <slaweq> lajoskatona: and also https://review.opendev.org/c/openstack/neutron/+/812658 if You'll have few minutes :)
09:21:25 <lajoskatona> slaweq: sure, checking
09:21:29 <slaweq> thx a lot
09:39:04 <opendevreview> huanghailun proposed openstack/neutron master: [ovn]Get network availability_zones from Logical_Switch  https://review.opendev.org/c/openstack/neutron/+/813599
09:49:24 <opendevreview> Lajos Katona proposed openstack/neutron-lib master: BFD validator  https://review.opendev.org/c/openstack/neutron-lib/+/809978
10:09:25 <opendevreview> Merged openstack/neutron-lib master: Rehome ``QuotaDriverAPI`` class  https://review.opendev.org/c/openstack/neutron-lib/+/811975
10:13:22 <opendevreview> liuyulong proposed openstack/neutron-specs master: Spec for distributed datapath for metadata  https://review.opendev.org/c/openstack/neutron-specs/+/802854
10:58:44 <opendevreview> Merged openstack/neutron master: [Policy] Set scope_types for BaseCheck rules  https://review.opendev.org/c/openstack/neutron/+/807559
11:22:06 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> Slawek Kaplonski proposed openstack/neutron master: Use ovs constants from neutron-lib  https://review.opendev.org/c/openstack/neutron/+/797120
12:29:06 <opendevreview> Slawek Kaplonski proposed openstack/neutron master: Remove ovs agent's common constants module  https://review.opendev.org/c/openstack/neutron/+/797121
12:29:50 <opendevreview> Merged openstack/neutron stable/xena: Fix OVN driver validating Geneve max_header_size  https://review.opendev.org/c/openstack/neutron/+/813346
12:29:54 <opendevreview> 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 <slaweq> 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 <lajoskatona> slaweq: ack
12:32:22 <slaweq> thx a lot
12:33:41 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> 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 <opendevreview> Przemyslaw Szczerbik proposed openstack/neutron-lib master: Add binding-profile.allocation converter  https://review.opendev.org/c/openstack/neutron-lib/+/813650
13:48:37 <opendevreview> 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 <opendevreview> 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 <opendevmeet> lajoskatona: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
14:00:36 <slaweq> hi
14:00:48 <mlavalle> you forgot to close tre previous meeting
14:00:54 <lajoskatona> hm....
14:00:55 <bcafarel> that previous meeting must have been a long-running one :)
14:00:59 <slaweq> :)
14:01:02 <lajoskatona> #endmeeting