| opendevreview | wushiming proposed openstack/neutron-vpnaas master: Drop install_venv https://review.opendev.org/c/openstack/neutron-vpnaas/+/809912 | 01:07 |
|---|---|---|
| opendevreview | Hemanth N proposed openstack/neutron master: set mac learning on ingress table to normal only for offload ports https://review.opendev.org/c/openstack/neutron/+/812641 | 05:48 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [Fullstack] Don't use dhcp in L3 agent tests https://review.opendev.org/c/openstack/neutron/+/813128 | 06:51 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Revert "Use 2 dhcp agents in TestLegacyL3Agent" https://review.opendev.org/c/openstack/neutron/+/813129 | 06:52 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/stein: Populate self.floating_ips_dict using "ip rule" information https://review.opendev.org/c/openstack/neutron/+/810396 | 07:22 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/rocky: Populate self.floating_ips_dict using "ip rule" information https://review.opendev.org/c/openstack/neutron/+/810427 | 07:22 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/queens: Populate self.floating_ips_dict using "ip rule" information https://review.opendev.org/c/openstack/neutron/+/810397 | 07:23 |
| lajoskatona | ralonsoh, obondarev: Hi could you check this requirement bumping patch for vpnaas when you have few minutes: https://review.opendev.org/c/openstack/neutron-vpnaas/+/811731 ,thanks in advance :-) | 07:37 |
| ralonsoh | lajoskatona, sure | 07:49 |
| lajoskatona | ralonsoh: thanks | 07:54 |
| songwenping | hello team, when i deploy devstack with ovn, and failed when reach `sudo systemctl restart ovs-vswitchd.service`, the status of ovs-vswitchd.service is `ovs|00007|bridge|ERR|another ovs-vswitchd process is running, disabling this process` | 08:12 |
| songwenping | anybody can help? | 08:13 |
| opendevreview | Rodolfo Alonso proposed openstack/networking-ovn stable/train: OVN git repository default branch is called "main" https://review.opendev.org/c/openstack/networking-ovn/+/813145 | 08:25 |
| opendevreview | Merged openstack/neutron-vpnaas master: req: Bump some requirements https://review.opendev.org/c/openstack/neutron-vpnaas/+/811731 | 08:28 |
| ralonsoh | slaweq, https://review.opendev.org/c/openstack/networking-ovn/+/813145 if you have time, please | 08:32 |
| opendevreview | Merged openstack/networking-ovn stable/train: Replace cirros 0.4.0 by 0.5.2 in ovn migration create-resources.sh.j2 https://review.opendev.org/c/openstack/networking-ovn/+/811430 | 08:34 |
| slaweq | ralonsoh: sure, checking | 08:39 |
| slaweq | ralonsoh: approved | 08:40 |
| slaweq | I made something similar for Neutron few days ago https://review.opendev.org/c/openstack/neutron/+/812674 | 08:40 |
| ralonsoh | slaweq, thanks and I'll review yours | 08:41 |
| slaweq | ralonsoh: thx :) | 08:41 |
| nautik | Hello! I am looking into the Segments extension and I have a few questions; anyone here knows about this and available for a chat? | 08:46 |
| nautik | I am looking into what is missing between neutron & placement to handle the case of multiple subnets on separate segments but within a single network | 08:47 |
| nautik | My use case: i want to display 1 network so that users don't have to wonder which one to select when they want an IP for their server. But within this network, I'd like to have separate v4 subnets (in different vlans). And of course, I'd like a port to get only 1 v4 ip, so I would need neutron to select only one of the v4 available subnets. | 08:53 |
| nautik | All segments are available on all hosts, so I don't need to impact novahost selection process | 08:54 |
| lajoskatona | nautik: Hi, that should work | 08:56 |
| nautik | But from what I think I see in neutron, the segments extension creates a resource provider in placement but the missing piece is that there is no logic of "selecting a segment with available v4 address" at the time of selecting subnets to get IPs from | 08:57 |
| nautik | is that correct? | 08:57 |
| nautik | (and also allocating resources, to update the "used" count of the IPV4_ADDRESS resource class in placement) | 08:58 |
| nautik | or did I miss something and this is supposed to work already? | 09:01 |
| lajoskatona | nautik: could you tell me which version of openstack you use? | 09:04 |
| nautik | I'm looking at ussuri's code | 09:04 |
| nautik | but on master I still see this check: https://opendev.org/openstack/neutron/src/branch/master/neutron/objects/subnet.py#L354 | 09:05 |
| lajoskatona | nautik: in wallaby there was some improvements in nova, but it's still not perfect (see my testcase: https://review.opendev.org/c/openstack/tempest/+/665155 which is not working) | 09:05 |
| lajoskatona | nautik: this was the nova change: https://review.opendev.org/c/openstack/nova/+/749068 | 09:05 |
| nautik | lajoskatona: oh thanks for the links; if I get this right, this change impacted nova host selection right ? | 09:08 |
| nautik | in my case this is not a problem as all hosts have all physical providers & segments available | 09:09 |
| nautik | so even if I add a request for network A when creating my server, I saw nova would add a "physical_network: B" constraint on host selection, but all hosts would verify it so no issue | 09:10 |
| nautik | my concern is more on the segment/subnet selection at the time of allocating IP to the port, when host is already selected. Which looks like it could be in the neutron merge request referenced in you link, but marked as "abandoned" | 09:15 |
| lajoskatona | nautik: yes, I had no time to work more on that, and it seemed from test results if I fix that part I break other usecases | 09:16 |
| lajoskatona | nautik: I wanted to discuss it with somebody deeper understanding of routed provider nets, but I had no time for it.... | 09:18 |
| nautik | lajoskatona: ok thanks for confirming; so I would say what remains to be done is to call placement to select segment candidates here: https://opendev.org/openstack/neutron/src/branch/master/neutron/objects/subnet.py#L350 | 09:20 |
| nautik | lajoskatona: would you agree? | 09:21 |
| nautik | I am not very familiar with neutron's code base so far =) | 09:22 |
| opendevreview | Rodolfo Alonso proposed openstack/networking-ovn stable/train: OVN git repository default branch is called "main" https://review.opendev.org/c/openstack/networking-ovn/+/813145 | 09:29 |
| lajoskatona | nautik: you can try https://review.opendev.org/c/openstack/neutron/+/777443 if it still solves the issue (with the linked tempest test is worked for me) | 09:36 |
| nautik | lajoskatona: this MR looks like it is only about updating the placement inventory right? Not impacting subnet selection | 09:38 |
| nautik | lajoskatona: my understanding on this inventory management topic was that the "reserved" field in placement was intended for counting "not usable" ips | 09:40 |
| nautik | but "allocated" count would be stored in the "used" field in placement, after storing new allocations in placement | 09:41 |
| nautik | looking at what I have in placement: https://pastebin.com/iNXB8H67 | 09:43 |
| nautik | comparing neutron's IPV4_ADDRESS resource class with what nova does for MEMORY_MB for example, I understand "reserved" is the amount of ram not available (used by the host) and "used" is what was allocated in placement for my servers | 09:45 |
| nautik | so the equivalent in neutron for IPV4_ADDRESS would be "reserved" for things like gateway ip & ports not attached, but when providing an ip to a port from a subnet in this segment, I'd say the "used" field would needs to be updated, which I guess in placement means making an allocation or reservation request | 09:47 |
| nautik | but some confirmations on this would be nice ^^ | 09:47 |
| lajoskatona | nautik: that's my understanding as well, but I am not sure if it ever worked like that. This is why I started adding some tests to have written agreement on how it should work | 09:49 |
| nautik | Yes it looks like the implementation was never completed | 09:57 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [Fullstack] Don't use dhcp in L3 agent tests https://review.opendev.org/c/openstack/neutron/+/813128 | 09:59 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Revert "Use 2 dhcp agents in TestLegacyL3Agent" https://review.opendev.org/c/openstack/neutron/+/813129 | 10:00 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [Fullstack] Don't use dhcp in L3 agent tests https://review.opendev.org/c/openstack/neutron/+/813128 | 10:27 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Revert "Use 2 dhcp agents in TestLegacyL3Agent" https://review.opendev.org/c/openstack/neutron/+/813129 | 10:27 |
| opendevreview | Merged openstack/neutron master: [Fullstack] Mark TestHAL3Agent fip_qos test as unstable https://review.opendev.org/c/openstack/neutron/+/813078 | 10:41 |
| opendevreview | Merged openstack/neutron stable/train: Populate self.floating_ips_dict using "ip rule" information https://review.opendev.org/c/openstack/neutron/+/810395 | 10:41 |
| *** elvira1 is now known as elvira | 10:57 | |
| opendevreview | Merged openstack/neutron stable/wallaby: Fix "_sync_metadata_ports" with no DHCP subnets https://review.opendev.org/c/openstack/neutron/+/812335 | 11:17 |
| opendevreview | Merged openstack/neutron stable/victoria: Fix "_sync_metadata_ports" with no DHCP subnets https://review.opendev.org/c/openstack/neutron/+/812336 | 11:34 |
| opendevreview | Merged openstack/neutron stable/ussuri: Fix "_sync_metadata_ports" with no DHCP subnets https://review.opendev.org/c/openstack/neutron/+/812337 | 11:34 |
| opendevreview | Daniel Alvarez proposed openstack/neutron master: [ovn] Clean up MAC_Binding entries with ovsdb-client https://review.opendev.org/c/openstack/neutron/+/812805 | 12: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 | 12:22 |
| 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 | 13:07 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [OVN Migration] Remove trunk's subports from the nodes https://review.opendev.org/c/openstack/neutron/+/813187 | 13:07 |
| lajoskatona | Dear Drivers team, I have some "logistical" problems (have to fetch my sons from the school) so I can start the meeting ~10 minutes later, sorry for it.... | 13:25 |
| ralonsoh | hehehe no problem | 13:25 |
| opendevreview | Rodolfo Alonso proposed openstack/networking-ovn stable/train: [OVN] Update the DHCP options when the metadata port is modified https://review.opendev.org/c/openstack/networking-ovn/+/812714 | 13:27 |
| opendevreview | Rodolfo Alonso proposed openstack/networking-ovn stable/train: [OVN] Set NB/SB "connection" inactivity probe https://review.opendev.org/c/openstack/networking-ovn/+/812304 | 13:27 |
| *** lbragstad_ is now known as lbragstad | 13:51 | |
| 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:06 |
| ralonsoh | slaweq, does it work? ^^^ | 14:07 |
| ralonsoh | if so, fantastic!! | 14:07 |
| slaweq | ralonsoh: locally for me it worked (with one test at least) | 14:08 |
| ralonsoh | very cool then | 14:08 |
| slaweq | I want to see in gate how it will be :) | 14:08 |
| slaweq | ralonsoh: also, such image works fine in the tobiko jobs in u/s ci | 14:14 |
| slaweq | so that's why I hope it will work and be a bit better in our case too :) | 14:14 |
| ralonsoh | for sure | 14:14 |
| lajoskatona2 | #startmeeting neutron_drivers | 14:14 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:14 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:14 |
| lajoskatona2 | Hi, sorry for being late.... | 14:14 |
| slaweq | hi | 14:14 |
| ralonsoh | hi | 14:14 |
| Gues__________________________ | o/ | 14:15 |
| *** Gues__________________________ is now known as ihrachys | 14:15 | |
| slaweq | LOL ihrachys nice new nick :P | 14:15 |
| slaweq | pretty long one | 14:15 |
| ihrachys | yeah. first time connected to this server | 14:15 |
| lajoskatona2 | not sure if we will have quorum, as mlavalle can't join today | 14:15 |
| lajoskatona2 | The topic for today: https://bugs.launchpad.net/neutron/+bug/1946251 | 14:17 |
| amotoki | hi | 14:18 |
| lajoskatona2 | Hi amotoki | 14:18 |
| slaweq | for that rfe I think we would need some "historical" background why it was such coupled always :) | 14:19 |
| slaweq | personally I don't see any issues with allowing to disable anti-spoofing and still have SG on the port | 14:20 |
| slaweq | but maybe there were good reasons for that in the past :) | 14:20 |
| ihrachys | a good start would be to formulate what the current port sec API does. it's not really described in api-ref. | 14:20 |
| ihrachys | so we can only assume, based on historical observations, that it disables both SG and anti-spoof | 14:21 |
| 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 |
| slaweq | so it's done on purpose I would say | 14:23 |
| ihrachys | clearly on purpose, so should be documented (in addition to explaining the intent of the API) | 14:24 |
| slaweq | I agree that this should be documented :) | 14:24 |
| amotoki | yeah, agree. it sould be documented | 14:24 |
| 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 |
| ihrachys | with SGs, it's possible by having a promiscuous SG | 14:24 |
| 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 |
| slaweq | something like that is already possible for ip_address | 14:25 |
| slaweq | as You can set 0.0.0.0 there | 14: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 |
| amotoki | MAC=ANY may confuse L2 switches though | 14:25 |
| ihrachys | that would be up to driver to interpret it (and declare support for this extension) | 14:25 |
| amotoki | but perhaps it would be a responsibility of who use it | 14:26 |
| ihrachys | alternatively, a new field could be added (port_spoofing_enabled=false) | 14:26 |
| ihrachys | I mean, anti* | 14:26 |
| slaweq | ihrachys: then we should also change logic for "port_security_enabled" field | 14:27 |
| slaweq | to not be dependen on allowed_address_pairs anymore | 14:27 |
| slaweq | right? | 14:27 |
| ihrachys | but first, let's maybe discuss if you believe the API is needed at all | 14:27 |
| ihrachys | ? | 14:27 |
| ihrachys | slaweq no why? we would keep original behavior, no? | 14:27 |
| 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 |
| ralonsoh | why should we change this behaviour? | 14:28 |
| slaweq | ihrachys: I'm not sure - just thinking | 14:29 |
| 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 |
| slaweq | how this new attribute port_antispoofing_enabled=false would work if we would have allowed_address_pairs for example? | 14:29 |
| 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 |
| 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:30 |
| 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 |
| ralonsoh | Why adding a new extension if we have "port_security_enabled"? | 14:31 |
| slaweq | IMHO the easiest way would be to add possibility of MAC=ANY in allowed_address_pairs to do that | 14:31 |
| ihrachys | ralonsoh because it disables both ACLs and anti-spoofing (apparently) | 14:31 |
| ihrachys | and some may want to have SG but not the other | 14:31 |
| ralonsoh | not ACLs, but I'll need to check that | 14:32 |
| ihrachys | SGs are verbotten with port_sec=false | 14:32 |
| ihrachys | checked on POST | 14:32 |
| lajoskatona | I found this old bug where the discussion can be interesting: https://bugs.launchpad.net/neutron/+bug/1453667 | 14:33 |
| slaweq | yes, currently SGs and allowed_address_pair are possible only when port_security_enabled = True | 14:33 |
| 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 |
| ihrachys | *for | 14:35 |
| ihrachys | but I assume port_sec=false == (SG=off AND anti-spoofing=off) as per code and historical observations | 14:36 |
| ihrachys | so just doc update needed there | 14:36 |
| slaweq | that's correct currently IMO | 14:36 |
| 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:36 |
| 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 |
| lajoskatona | but otherwise I can't see why we cant decouple the 2, allowed-address -pairs and sec-groups | 14:37 |
| slaweq | and port_Security would be related only to SGs | 14:37 |
| 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 |
| slaweq | or am I misunderstanding it? | 14:37 |
| ihrachys | slaweq no you can't change behavior for existing API | 14:38 |
| lajoskatona | slaweq: yeah that's my understanding | 14:38 |
| ihrachys | so port_sec would still do what it does now - disable both | 14:38 |
| ralonsoh | right, we can't change current API | 14:38 |
| lajoskatona | and if I understand well the MAC=any or multimac is another feature, | 14:38 |
| amotoki | ihrachys: yeah, IIRC more (IP, MAC) pair is allowed and it is expected | 14:38 |
| ralonsoh | but we can add the anti-spoofing API | 14:38 |
| 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 |
| 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:39 |
| slaweq | and IMO we should simly allow to set ANY MAC in the AAP field | 14:40 |
| slaweq | as we already allow for IP addresses there | 14:40 |
| slaweq | and by that kind of "bypass" antispoofing protection for port | 14:40 |
| lajoskatona | slaweq: +1 | 14:40 |
| ihrachys | slaweq it sucks I admit. yes, overloading seems like a more clean way of doing it but I may be wrong. | 14:40 |
| ralonsoh | but that will require support from each specific backend FW | 14:41 |
| ihrachys | note for IPs we do masks, where /0 means ANY | 14:41 |
| ralonsoh | I don't know if this is possible in OVS FW or iptables or OVN | 14:41 |
| ihrachys | for MACs, I guess masks are useless, or? | 14: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 | 14:41 |
| dalvarez | lucasagomes: ^ | 14:41 |
| dalvarez | 75 GB down to 7GB \o/ | 14:41 |
| slaweq | ihrachys: You're right | 14:42 |
| ihrachys | ralonsoh can | 14:42 |
| lucasagomes | dalvarez, ohh yeah | 14:42 |
| 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:43 |
| amotoki | what do you mean by ANY AAP? Any IP or Any MAC? | 14:44 |
| ihrachys | ANY MAC AAP | 14:44 |
| ihrachys | (I am not shouting, it's acronym soup) | 14:44 |
| ralonsoh | to be honest, I need to see the implementation. But of course, it worths to go this direction | 14:44 |
| slaweq | ihrachys: for ANY IP address in AAP agent will add /0 IP into ipset or OF rules in br-int | 14:45 |
| slaweq | to allow egress traffic with IPs from that CIDR from this port | 14:45 |
| slaweq | I don't know how hard it may be to do the same for "ANY" MACs eg. in ovs case | 14:46 |
| ralonsoh | in OVS we can disable "provides_arp_spoofing_protection" in the FW | 14:46 |
| ralonsoh | well, for all of them, never mind | 14:46 |
| 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:46 |
| 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 |
| ralonsoh | yes, that's what I understand | 14:47 |
| 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:47 |
| 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 |
| slaweq | that would disable it completly, no? | 14:48 |
| amotoki | I am a bit confused. why do we need to downe AAP if ANY MAC is specified? | 14:48 |
| ralonsoh | ihrachys, I need to check that in iptables and OVS FW | 14:48 |
| amotoki | s/downe/down/ | 14:48 |
| ihrachys | lajoskatona that's my understanding, yes | 14:48 |
| 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:49 |
| ihrachys | if it's a flag like port_security, it's the former | 14:50 |
| 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 |
| lajoskatona | if a flag like thing than I would make it simpler like allowed_address_pairs=False or similar | 14:50 |
| ihrachys | what do you mean "simpler" | 14:51 |
| 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:51 |
| 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 |
| 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 |
| lajoskatona | yeah for that the API would be changed to allow list or bool, that's true | 14:52 |
| slaweq | I don't think it's good idea to accept 2 types as the allowed_address_pairs | 14:53 |
| ihrachys | list or bool sounds like not the best API | 14:54 |
| slaweq | ihrachys++ | 14:54 |
| lajoskatona | ok, than it's not a simple flag, we have to always fill the whole ip=...mac=.... fields | 14:54 |
| 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 |
| 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 |
| lajoskatona | do we need a spec for it to see more details written? | 14:55 |
| 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 |
| 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 |
| ihrachys | slaweq yes, that would kill all checks | 14:56 |
| slaweq | lajoskatona: +1 for spec with short description of various possible solutions for that | 14:57 |
| amotoki | why IP address check needs to be disabled? IP of AAP is also used in remote group in SG API | 14:57 |
| 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:57 |
| 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 |
| 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 |
| ihrachys | ok I can write a spec next week | 14:59 |
| lajoskatona | ihrachys: thanks | 14:59 |
| slaweq | +1 for spec and for voting on it next week when we will have quorum | 15:00 |
| ralonsoh | +1 to the idea (I need the spec to check the implementation) | 15:00 |
| 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 |
| slaweq | or if we will not have quorum, to discuss it in details during ptg :) | 15:00 |
| lajoskatona | slaweq: +1 | 15:00 |
| lajoskatona | I just wanted to mention that the week after w have PTG, and can have more discussion :-) | 15:01 |
| 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 |
| slaweq | ++ | 15:01 |
| ihrachys | thanks for consideration | 15:01 |
| lajoskatona | ok, I think we can't do more today, thanks everybody for participating and sharing ideas | 15:01 |
| slaweq | o/ | 15:01 |
| ralonsoh | have a nice weekend | 15:02 |
| amotoki | thanks all. have a good weekend | 15:02 |
| slaweq | have a great weekend | 15:02 |
| lajoskatona | Have a nice weekend, bye | 15:02 |
| lajoskatona | #endmeeting | 15:02 |
| opendevreview | Merged openstack/neutron stable/xena: Fix "_sync_metadata_ports" with no DHCP subnets https://review.opendev.org/c/openstack/neutron/+/812334 | 15:24 |
| 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 |
| 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:35 |
| 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 |
| 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:36 |
| mloza | hello, how can I trigger rescheduling of L3 and DHCP agents of a router ? | 15:45 |
| 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:05 |
| 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:08 |
| opendevreview | Rodolfo Alonso proposed openstack/os-ken master: Update bridge.py https://review.opendev.org/c/openstack/os-ken/+/813216 | 16:09 |
| 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:14 |
| opendevreview | Daniel Speichert proposed openstack/neutron master: Fixes OVN driver validating Geneve max_header_size https://review.opendev.org/c/openstack/neutron/+/813230 | 16:56 |
| 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 |
| 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:17 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP][OVN] Sync QoS policies https://review.opendev.org/c/openstack/neutron/+/813052 | 17:19 |
| 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 |
| 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:34 |
| 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:43 |
| 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 | 17:57 |
| 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 |
| *** tbachman is now known as Guest2264 | 23:35 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!