| opendevreview | Kyuyeong Lee proposed openstack/neutron master: db: Add port group models https://review.opendev.org/c/openstack/neutron/+/1006171 | 04:21 |
|---|---|---|
| opendevreview | Kyuyeong Lee proposed openstack/neutron master: objects: Add port group objects https://review.opendev.org/c/openstack/neutron/+/1006172 | 04:21 |
| opendevreview | Kyuyeong Lee proposed openstack/neutron master: api: Add port group CRUD https://review.opendev.org/c/openstack/neutron/+/1006173 | 04:21 |
| opendevreview | Kyuyeong Lee proposed openstack/neutron master: sg: Support ``port_group_id`` in security group rules https://review.opendev.org/c/openstack/neutron/+/1008389 | 04:21 |
| opendevreview | Kyuyeong Lee proposed openstack/neutron master: ovn: Translate port groups to ACL match expressions https://review.opendev.org/c/openstack/neutron/+/1008390 | 04:21 |
| opendevreview | Kyuyeong Lee proposed openstack/neutron master: sg: Expand port groups for agent based drivers https://review.opendev.org/c/openstack/neutron/+/1008391 | 04:21 |
| opendevreview | Kyuyeong Lee proposed openstack/neutron master: ovn: Propagate port group changes to the ACLs https://review.opendev.org/c/openstack/neutron/+/1008392 | 04:21 |
| opendevreview | Kyuyeong Lee proposed openstack/neutron master: tests: Add functional tests for port groups https://review.opendev.org/c/openstack/neutron/+/1008393 | 04:21 |
| opendevreview | Kyuyeong Lee proposed openstack/neutron master: doc: Document port groups https://review.opendev.org/c/openstack/neutron/+/1008394 | 04:21 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/neutron master: Fix: per-gateway SNAT settings not persisted in multi-gateway routers https://review.opendev.org/c/openstack/neutron/+/971593 | 07:39 |
| opendevreview | Kyuyeong Lee proposed openstack/neutron master: [OVN] Retrieve only the SG stateful flag in the logapi driver https://review.opendev.org/c/openstack/neutron/+/1008419 | 07:45 |
| opendevreview | Lajos Katona proposed openstack/neutron master: Use SDK for Nova notifications https://review.opendev.org/c/openstack/neutron/+/983905 | 08:14 |
| opendevreview | Merged x/whitebox-neutron-tempest-plugin master: Revert "Workaround Nova bug to fix `test_qos_after_live_migration` coverage" https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/1005528 | 08:16 |
| opendevreview | Chris Buggy proposed openstack/neutron master: Do not advertise router gateway and metadata server IPs https://review.opendev.org/c/openstack/neutron/+/1006001 | 08:21 |
| opendevreview | Merged x/whitebox-neutron-tempest-plugin master: Detect DevStack on remote nodes over SSH https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/1007468 | 09:16 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: ovn: fix gateway scheduling for multi-segment networks https://review.opendev.org/c/openstack/neutron/+/1007885 | 09:21 |
| opendevreview | Bharath M V proposed openstack/neutron-tempest-plugin master: [TaaS] Add MTU and Cross-tenant test to Tap-as-a-Service. https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/1006184 | 09:47 |
| ralonsoh | lajoskat1na, hi! if you have a couple of mins: https://review.opendev.org/c/openstack/neutron-lib/+/1006916 | 10:24 |
| ralonsoh | no rush | 10:24 |
| ralonsoh | and https://review.opendev.org/c/openstack/neutron/+/1003914, if possible | 10:25 |
| opendevreview | Lajos Katona proposed openstack/neutron master: Replace legacy Ironic and Nova auth opts and remove novaclient https://review.opendev.org/c/openstack/neutron/+/1008433 | 10:26 |
| opendevreview | Merged openstack/neutron master: Add OpenTelemetry tracing middleware for Neutron https://review.opendev.org/c/openstack/neutron/+/1007753 | 11:03 |
| opendevreview | Eduardo Olivares proposed openstack/neutron master: DNM == Stress the BGP job IPv6 DAD fix https://review.opendev.org/c/openstack/neutron/+/1004573 | 11:24 |
| opendevreview | Eduardo Olivares proposed openstack/neutron master: DNM == Stress the BGP job IPv6 DAD fix https://review.opendev.org/c/openstack/neutron/+/1004573 | 11:24 |
| opendevreview | Merged openstack/neutron-vpnaas stable/2026.2: Add support for ``vpn-aes-ccm-gcm`` API extension https://review.opendev.org/c/openstack/neutron-vpnaas/+/1006474 | 11:36 |
| opendevreview | Merged openstack/neutron-vpnaas stable/2026.2: Add support for ``vpn-no-sha1-3des`` API extension https://review.opendev.org/c/openstack/neutron-vpnaas/+/1006475 | 11:36 |
| opendevreview | Stephen Finucane proposed openstack/os-vif master: trivial: Fix indentation in pyproject.toml https://review.opendev.org/c/openstack/os-vif/+/1008450 | 12:17 |
| opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: dns_forwarder extension: add extension to distributed dhcp job https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/958775 | 12:31 |
| opendevreview | Merged openstack/neutron master: iptables: Rely on iptables-restore -w lock instead of oslo lock https://review.opendev.org/c/openstack/neutron/+/1007422 | 12:40 |
| opendevreview | Merged openstack/neutron master: Remove ``ovs_create_tap`` configuration options https://review.opendev.org/c/openstack/neutron/+/1008014 | 12:41 |
| stephenfin | ralonsoh: apologies for the direct ping, but has something changed with the neutron address scope API recently? We're seeing failures in the OSC gate, e.g. https://zuul.opendev.org/t/openstack/build/82082b6ecf624c2199ca8bdba9efa0ae | 12:49 |
| ralonsoh | stephenfin, yes, one sec | 12:56 |
| ralonsoh | stephenfin, https://review.opendev.org/c/openstack/neutron/+/887965 | 12:56 |
| ralonsoh | so this test should be removed, or anything related to addressscope.shared | 12:57 |
| ralonsoh | stephenfin, let me push a patch | 12:57 |
| stephenfin | good thing I asked :) ty 🙏 ralonsoh++ | 12:58 |
| slaweq | hi, do we have drivers meeting today? | 13:02 |
| mlavalle | I was about to ask the same thing | 13:02 |
| mlavalle | haleyb, are we meeting today? | 13:03 |
| haleyb | sorry, had a filesystem failure, had to reboot and fsck | 13:03 |
| haleyb | yes planned on meeting, let me find the agenda | 13:04 |
| haleyb | #startmeeting neutron_drivers | 13:06 |
| opendevmeet | Meeting started Fri Oct 2 13:06:11 2026 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. | 13:06 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:06 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 13:06 |
| haleyb | Ping list: ykarel, mlavalle, mtomaska, slaweq, tobias-urdin, lajoskatona, haleyb, ralonsoh, cardoe | 13:06 |
| mlavalle | \o | 13:06 |
| ralonsoh | hello | 13:06 |
| cardoe | o/ | 13:06 |
| frickler | ralonsoh: shared address scopes are used in https://docs.openstack.org/neutron-dynamic-routing/latest/install/usecase-ipv6.html#address-scope , can someone do an update for this? | 13:06 |
| slaweq | o/ | 13:06 |
| lajoskatona__ | o/ | 13:06 |
| frickler | ah, let's talk after the meeting | 13:06 |
| haleyb | sorry for being late, system decided to do other things | 13:07 |
| haleyb | we can get started | 13:08 |
| haleyb | first rfe on the list is from slaweq | 13:08 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2167078 | 13:08 |
| haleyb | [RFE] Allow reschedule of the routes to the nodes in different availability zone | 13:08 |
| slaweq | yeah, it is pretty simple thing I guess | 13:10 |
| slaweq | I described the use case in LP already | 13:10 |
| slaweq | so if you have any questions, please ask :) | 13:10 |
| haleyb | is setting the AZ an admin operation? | 13:10 |
| cardoe | It's a great suggestion | 13:10 |
| haleyb | i.e. in a POST | 13:10 |
| slaweq | I think that any user can set az-hints in POST | 13:11 |
| cardoe | haleyb: so it almost seems like it'd be really user specific but we'd have to have some guard rails around what valid values somehow. | 13:11 |
| ralonsoh | of course, that will imply the GW chassis re-assignation and a possible network disconnection (to be documented), right? | 13:12 |
| cardoe | today in nova you can set scheduler hints and mess with the AZs as the user | 13:12 |
| slaweq | ralonsoh: yes, of course | 13:12 |
| slaweq | haleyb: I just checked in https://github.com/openstack/neutron/blob/master/neutron/conf/policies/router.py that there is no special policy for that so it can be done by MEMBER users | 13:12 |
| haleyb | cardoe: i'm not sure if there is a validity check today to tell you the truth, i think you can just specify a list | 13:13 |
| lajoskatona__ | is there any reason to make the set as admin_only? | 13:13 |
| slaweq | lajoskatona__: I don't think so | 13:13 |
| ralonsoh | the owner of this router should be able to do it | 13:14 |
| ralonsoh | IMO | 13:14 |
| slaweq | if user can already set it during the creation of router, then why not update it? | 13:14 |
| ralonsoh | not only an admin | 13:14 |
| cardoe | slaweq: what you're describing would actually model really well to the VXLAN underlay fabric spec | 13:14 |
| ralonsoh | but that can be discussed in the patch, I think | 13:14 |
| lajoskatona__ | +1, thanks | 13:14 |
| haleyb | i just hadn't looked at the API, but think it's ok to change if we can set at create | 13:14 |
| cardoe | This is the case I'm trying to handle with the physical servers. | 13:14 |
| slaweq | cardoe: true, but that wasn't my "primary goal" :) | 13:14 |
| haleyb | anyway, seems straightforward | 13:15 |
| slaweq | haleyb: here is api definition https://github.com/openstack/neutron-lib/blob/9253e435e8dee64cb8339cd71512ce44aafb518c/neutron_lib/api/definitions/router_availability_zone.py#L39 | 13:15 |
| cardoe | slaweq: of course I'm just saying there's some cross over with what I've wanted in that data center VXLAN fabric stuff. | 13:15 |
| ralonsoh | do we need a spec for this? I'm not sure, to be honest. Good docs yes | 13:15 |
| cardoe | haleyb: that's what I'm trying to say at least that we want some kind of awareness (we being my organization) but not really exposing real details. | 13:16 |
| slaweq | ralonsoh: the spec would be pretty short and trivial I guess | 13:16 |
| mlavalle | I don't think a spec is needed. It seems pretty straightforward to me | 13:16 |
| haleyb | cardoe: i don't understand the "not really exposing real details" there | 13:17 |
| ralonsoh | I think the same, spec is not needed | 13:17 |
| haleyb | and i don't think a spec is needed either, just documentation | 13:17 |
| ralonsoh | so +1 from me | 13:17 |
| lajoskatona__ | +1 | 13:17 |
| mlavalle | +1 | 13:17 |
| haleyb | +1 from me as well | 13:17 |
| cardoe | So in slaweq's case of different parts of the DC and it being inefficient. I wanna load in some kind of stand in values so that it's clear that this box is now at AZ-1 and the router is in AZ-2 so its less good. | 13:18 |
| haleyb | i will mark it approved then, thanks slaweq | 13:18 |
| cardoe | But the name AZ-1 and AZ-2 might not be useful for cloud operators so they might be tempted to use real internal naming at the provider for it to be useful. | 13:18 |
| slaweq | thank you | 13:18 |
| cardoe | But they don't want to expose that necessarily to users of the API which might be external. | 13:19 |
| cardoe | Nova does this with the hypervisor hostname field | 13:19 |
| cardoe | They expose to the user a UUID value while to admins they expose the real hypervisor hostname. | 13:19 |
| ralonsoh | sorry folks, we have 5 specs for today | 13:19 |
| haleyb | cardoe: but we have to assume the user knows what they are doing, right? if AZ-77 has no meaning they will need to fix it | 13:19 |
| slaweq | cardoe: IIUC that would be yet another RFE I guess | 13:19 |
| cardoe | yeah move on from what I'm saying. | 13:20 |
| haleyb | but we do have other specs to discuss | 13:20 |
| haleyb | i'm not sure if chanyeol is here? | 13:20 |
| cyyoon__ | o/ yes, I'm here. these two are mine (ycy1766 on launchpad) | 13:20 |
| haleyb | cyyoon__: ok, great let's talk about the first one | 13:21 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2168007 | 13:21 |
| haleyb | [RFE] Tap-as-a-Service: mirror a port to another Neutron port (OVN lport mirror) | 13:21 |
| cyyoon__ | We'd like tap mirrors to send copies to another Neutron port using the OVN "lport" mirror type (25.09+), instead of only a remote IP over gre/erspan. | 13:22 |
| lajoskatona__ | I asked in comment in launchpad, and the answer seems reasonable to use the tap-mirror and not the tap-service/tap-flow API for this new extension | 13:22 |
| cyyoon__ | thanks lajoskatona__ We'd like tap mirrors to send copies to another Neutron port using the OVN "lport" mirror type (25.09+), instead of only a remote IP over gre/erspan, so the collector never sees hypervisor addresses. Code is done and tested e2e on OVN 26.03. | 13:22 |
| lajoskatona__ | Is this lport mirror uses some encapsulation like the original mirroring with GRE/erspan? | 13:23 |
| cyyoon__ | no, the copies ride the existing geneve overlay to the sink's chassis and are delivered to the collector as the original frames, no extra encapsulation. | 13:24 |
| lajoskatona__ | ack, thanks | 13:24 |
| slaweq | so this sounds for me like pretty small and straightforward change | 13:25 |
| slaweq | one question - is this going to be supported only by ml2/ovn backend or do you have plans to implement the same for ml2/ovs too? | 13:25 |
| cyyoon__ | only ml2/ovn for now, since it's built on the OVN lport mirror. | 13:26 |
| mlavalle | well, the rfe specifically talks about ovn lports | 13:26 |
| mlavalle | the rfe proposes to leverage something new in core OVN | 13:26 |
| ralonsoh | I'm also ok with this feature with the proper documentation (quite short in this repo) | 13:27 |
| cyyoon__ | right, it's the lport mirror type added in OVN 25.09 | 13:27 |
| slaweq | ok, that's what I though but wanted to make sure | 13:27 |
| ralonsoh | Also a parity gap table between ovs and ovn | 13:27 |
| cyyoon__ | sure, I'll add proper docs to taas with it | 13:27 |
| lajoskatona__ | +1 | 13:27 |
| ralonsoh | So +1 from me (without spec) | 13:27 |
| mlavalle | +1 | 13:27 |
| haleyb | +1 from me as well | 13:28 |
| cyyoon__ | and the ovs/ovn parity table too, thanks | 13:28 |
| haleyb | cyyoon__: i will approve it, thanks for working on it | 13:28 |
| slaweq | +1 | 13:28 |
| cyyoon__ | thanks all! the second one builds on this one | 13:28 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2168008 | 13:29 |
| haleyb | [RFE] Tap-as-a-Service: filtering rules for lport tap mirrors (OVN Mirror_Rule) | 13:29 |
| cyyoon__ | this adds filtering rules to lport mirrors via OVN Mirror_Rule, so you can mirror only what you need, e.g. tcp/443. no rules means everything is mirrored, like today | 13:29 |
| lajoskatona__ | really good idea | 13:30 |
| ralonsoh | so a granular mirror? that implies a new API, right? | 13:30 |
| ralonsoh | and OVN only, if I'm not wrong | 13:30 |
| mtomaska__ | I need to read more in depth but I was expecting for such RFE to come in one day :) | 13:31 |
| cyyoon__ | yes, a new "rules" sub-resource under tap mirrors, similar to QoS policy rules | 13:31 |
| mlavalle | and again, just bringing to the TAAS level something that OVN already does | 13:31 |
| cyyoon__ | yes, OVN only, since Mirror_Rule only applies to lport mirrors | 13:31 |
| lajoskatona__ | I am thinking if mixxing the 2 thing "legacy" mirrors with lport is really a good idea | 13:32 |
| slaweq | as mtomaska__ said - this is kinda natural improvement for tapaas IMO | 13:32 |
| ralonsoh | this time, due to the DB/API changes, I would expect a spec. And proper testing!! But I'm Ok with it | 13:33 |
| cyyoon__ | rules are only accepted on lport mirrors and live in a separate extension, gre/erspan mirrors are untouched. but I'm open to splitting it if you prefer | 13:33 |
| lajoskatona__ | that API has fields that are not valid for this loprt one, and the lport one will have fields that are only for lport mirrors | 13:33 |
| cyyoon__ | fair point. I'll write a spec for 2027.1 and cover the API shape there, including a separate lport resource as an option, plus the tests | 13:33 |
| ralonsoh | cyyoon__, so this rules filter can be applied to both hypervisor IP and other port? | 13:33 |
| haleyb | and the rules are similar to SG rules i guess | 13:33 |
| cyyoon__ | ralonsoh: only lport mirrors, OVN Mirror_Rule doesn't apply to gre/erspan | 13:34 |
| ralonsoh | ooook (so --> documentation heheheh) | 13:34 |
| cyyoon__ | haleyb: yes, same vocabulary as SG rules, plus a priority and mirror skip | 13:34 |
| ralonsoh | why not the other? just asking | 13:34 |
| ralonsoh | why is not possible to filter for hypervisor IP? | 13:34 |
| cyyoon__ | noted, it'll be in the docs :) | 13:34 |
| lajoskatona__ | yeah we havwe to make sure that it is clear for enduser that lport can have filtering rules and not the legacy mirrors | 13:35 |
| cyyoon__ | ralonsoh: in OVN gre/erspan are plain OVS port mirrors set up by ovn-controller, no logical flows. Mirror_Rule matches live in the lport mirror stages of the pipelin e | 13:36 |
| ralonsoh | ahhhhh | 13:36 |
| cyyoon__ | lajoskatona__: agreed, the API will reject rules on gre, erspan mirrors and the docs will say so | 13:36 |
| lajoskatona__ | ok, that is usefull information, to see the difference under th hood in OVN | 13:36 |
| ralonsoh | for sure | 13:36 |
| ralonsoh | So +1 from me (with spec). Nice feature | 13:37 |
| cyyoon__ | thanks, I'll put that in the spec too. | 13:37 |
| mlavalle | +1 from me | 13:37 |
| slaweq | +1 from me too | 13:37 |
| mtomaska_ | sorry I am double-booked in two meetings... but I think the RFE is good. We do need to some cleanup in the tap API. It is weird how it mixes old tap flow(OVS) with new tap mirror(OVN) | 13:37 |
| mtomaska_ | +1 from me | 13:37 |
| mtomaska_ | ill comment on the LP after I am done with meetings | 13:37 |
| haleyb | +1 from me as well | 13:38 |
| opendevreview | Merged openstack/neutron stable/2026.1: bgp: Use NIC types when obtaining peer NIC https://review.opendev.org/c/openstack/neutron/+/1007629 | 13:38 |
| cyyoon__ | mtomaska_: agreed, I'll look at that cleanup in the spec as well. | 13:38 |
| opendevreview | Merged openstack/neutron master: Do not re-ACTIVE ports on DHCP ready without provisioning blocks https://review.opendev.org/c/openstack/neutron/+/1007683 | 13:38 |
| lajoskatona__ | thanks mtomaska_ for checking | 13:38 |
| lajoskatona__ | +1 | 13:38 |
| haleyb | cyyoon__: i will approve, you can go ahead with specs for both and we can continue comments there | 13:38 |
| haleyb | again, thanks for working on it | 13:38 |
| cyyoon__ | will do, thanks everyone! one more thing: the spec for the ACL flow sampling RFE from Sep 11 is up at https://review.opendev.org/c/openstack/neutron-specs/+/1005660, reviews welcome when you have time | 13:39 |
| mlavalle | I think we agreed no spec was necessary for the first rfe | 13:39 |
| ralonsoh | ^ right | 13:39 |
| haleyb | ah, i missed that | 13:39 |
| mlavalle | so only was spec is needed | 13:40 |
| mlavalle | cyyoon__, **** | 13:40 |
| cyyoon__ | mlavalle: got it, spec only for the rules one. thanks! | 13:41 |
| haleyb | next rfe was from philip dale but i don't know if he is here | 13:41 |
| haleyb | we can move on to rodolfo's and come back if necessary | 13:42 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2168770 | 13:42 |
| haleyb | [RFE] ml2: remove allocated flag from allocation tables — use networksegments as single source of truth | 13:42 |
| mlavalle | haleyb, maybe add that rfe to the PTG agenda | 13:42 |
| ralonsoh | In a nutshell: I want to remove unnecessary tables from the DB | 13:43 |
| ralonsoh | there is no need to keep the ml2_*_allocations when we already have networksegments table | 13:43 |
| ralonsoh | in order to find the next free ID for a network type, is just a matter of 1) reading networksegments, 2) reading the config and 3) reading the network defined segments | 13:44 |
| slaweq | can we delete tables during the alembic migration? Will it be fine from the upgrade perspective and allowed in the EXPAND? | 13:44 |
| ralonsoh | no and yes | 13:44 |
| ralonsoh | we can add exceptions in a expand migration | 13:44 |
| ralonsoh | but | 13:44 |
| ralonsoh | we had problems with that before if you need to do a revert during the migration | 13:44 |
| slaweq | yeah, I know we can add expections, but my question was more if we really should do it :) | 13:45 |
| ralonsoh | so the safer is to mark the tables to be removed | 13:45 |
| ralonsoh | and remove then 1 SLURP release later | 13:45 |
| slaweq | I'm ok with stop using those tables but keep in them in the db would be IMHO better then removing them from schema | 13:45 |
| ralonsoh | we have done this before | 13:46 |
| ralonsoh | it is fine if we delay that | 13:46 |
| ralonsoh | to avoid upgrade problems | 13:46 |
| slaweq | ++ | 13:47 |
| ralonsoh | about how to keep the networksegments safe: add a SQL constraint so it won't be possible for 2 workers to reserve the same ID | 13:47 |
| ralonsoh | --> the second worker will fail | 13:47 |
| ralonsoh | of course, we have a randomizer method to retrieve the ID from the free ones, so it's uncommon that 2 workers request the same one | 13:47 |
| ralonsoh | that's all | 13:47 |
| ralonsoh | ah | 13:47 |
| ralonsoh | why this? to avoid problems like this one | 13:48 |
| ralonsoh | https://bugs.launchpad.net/neutron/+bug/2167266 | 13:48 |
| ralonsoh | or other sync problem between the ml2_*_reservations and networksegments | 13:48 |
| haleyb | i was going to ask if cardoe had an opinion on this | 13:48 |
| mlavalle | I think cleaning up the messes we have created over the years makes perfect sense | 13:49 |
| haleyb | i agree | 13:49 |
| mlavalle | "The allocation tables were the only record of what was in use when introduced in Grizzly (2013). The networksegments table, promoted in Mitaka (2016), made them fully redundant." illustrates how we create those messes | 13:50 |
| haleyb | and i don't think we need a spec for this since it's really just internal changes | 13:50 |
| mlavalle | agree | 13:51 |
| slaweq | haleyb: I agree too | 13:51 |
| lajoskatona__ | +1 | 13:51 |
| haleyb | ok, we can vote, +1 from me | 13:51 |
| mlavalle | +1 | 13:51 |
| slaweq | +1 | 13:51 |
| lajoskatona__ | +1, let's make db simpler :-) | 13:51 |
| ralonsoh | thanks | 13:52 |
| haleyb | so the one we skipped was this one | 13:53 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2168526 | 13:53 |
| haleyb | [RFE] EVPN: allow a dual-stack network to advertise both address families | 13:53 |
| ichen | I didn’t write this RFE, but this is actually something that is useful. | 13:54 |
| ralonsoh | (I was going to summon you...) | 13:54 |
| haleyb | philip doesn't seem to be here, not sure if anyone had an opinion on it | 13:54 |
| ichen | In a way, our current code probably restricted it too much. | 13:54 |
| ichen | Our current code restricts one subnet per network. But it should be one subnet per address family per network. | 13:55 |
| mlavalle | so the rfe makes sense | 13:55 |
| ichen | In my opinion, API doesn’t need to change. | 13:55 |
| lajoskatona__ | sounds great, thanks for the background | 13:56 |
| ralonsoh | ichen, qq, is this current limitation documented? | 13:57 |
| haleyb | and the submittor has a patch ready to go... | 13:57 |
| ichen | I’m not sure. I’ll need to check. I think there’s an error message. | 13:57 |
| ichen | Check about documentation of the limitation. | 13:57 |
| haleyb | does anyone have an objection to treating this as a bug fix and doc update? | 13:59 |
| mlavalle | I don't | 13:59 |
| ichen | Would the documentation be in the release notes here? https://docs.openstack.org/releasenotes/neutron/2026.2.html | 13:59 |
| slaweq | it seems like a bug for me | 13:59 |
| ralonsoh | ok for me, as long as we never documented it | 13:59 |
| ichen | For what it’s worth, there’s no mention of EVPN in the 2026.2 release note. | 14:00 |
| ralonsoh | make it a bug then | 14:00 |
| haleyb | ok, seems we are in agreement, i will update the bug with this info | 14:00 |
| lajoskatona__ | thanks | 14:01 |
| mlavalle | just on time | 14:01 |
| haleyb | and we are out of time, thanks for attending everyone and have a nice weekend! | 14:01 |
| mlavalle | top of the hour | 14:01 |
| haleyb | #endmeeting | 14:01 |
| opendevmeet | Meeting ended Fri Oct 2 14:01:27 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-10-02-13.06.html | 14:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-10-02-13.06.txt | 14:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-10-02-13.06.log.html | 14:01 |
| mlavalle | \o | 14:01 |
| ichen | thanks! | 14:01 |
| ralonsoh | bye | 14:01 |
| slaweq | o/ | 14:02 |
| lajoskatona__ | o/ | 14:02 |
| slaweq | have a great weekend | 14:02 |
| cardoe | haleyb: ralonsoh: I apologize. TheJulia called and we were discussing a security issue I ran into. | 14:03 |
| haleyb | ralonsoh: hey rodolfo - is terry around? my colleague was just looking for a response on https://review.opendev.org/c/openstack/neutron/+/989565 to try and move it forward | 14:03 |
| ralonsoh | I think so, I'll ping him internally | 14:03 |
| cardoe | I'm utilizing https://review.opendev.org/c/openstack/neutron/+/985732 to close the security bug for very generic context. | 14:03 |
| cardoe | I'm +1 on what ralonsoh is aiming for with the clean up of ml2 allocations. I believe he has an old bug about performance around that table. | 14:06 |
| ralonsoh | I'll check this patch today, I'm in another meeting now | 14:06 |
| haleyb | ralonsoh: sure, and thanks! | 14:07 |
| *** haleyb_ is now known as haleyb | 14:07 | |
| wilkmarcin | hey ralonsoh, if you have a chance to talk to Terry, could you please ask him to take a look at https://review.opendev.org/c/openstack/neutron/+/989565? | 14:08 |
| ralonsoh | wilkmarcin, yes, this is what I said before | 14:09 |
| wilkmarcin | oh, thank. I must have misunderstood you. sorry | 14:10 |
| wilkmarcin | thanks ^ | 14:11 |
| opendevreview | Lajos Katona proposed openstack/tap-as-a-service master: Extract DB model classes into models https://review.opendev.org/c/openstack/tap-as-a-service/+/995059 | 14:13 |
| opendevreview | Lajos Katona proposed openstack/tap-as-a-service master: Remove nested DB context decorators from private getter methods https://review.opendev.org/c/openstack/tap-as-a-service/+/995060 | 14:13 |
| opendevreview | Lajos Katona proposed openstack/tap-as-a-service master: Introduce OVO objects for TaaS resources https://review.opendev.org/c/openstack/tap-as-a-service/+/995061 | 14:13 |
| opendevreview | Lajos Katona proposed openstack/tap-as-a-service master: Use new OVO classes in Taas_db_Mixin https://review.opendev.org/c/openstack/tap-as-a-service/+/998629 | 14:13 |
| cardoe | I'm wondering about the router object with it's status and admin_state_up fields. I'm not sure what the possible values are here. But I'm speaking with ichen about some of the EVPN work and the FSM that's used. I was wondering if it would be possible to put a router object into status CONFIGURING maybe and then return back to ACTIVE once it was done? | 14:17 |
| cardoe | Potentially even having status of ERROR to signify something went wrong? | 14:18 |
| frickler | haleyb: ralonsoh: regarding address-scope.shared I already commented on https://review.opendev.org/c/openstack/openstacksdk/+/1008457, but I really wonder how neutron can change the API in such a way at all | 14:42 |
| frickler | and even if you do, documenting how the RBAC based solution should look like and updating affected neutron docs like the n-d-r guide I mentioned above would be nice | 14:44 |
| ralonsoh | frickler, because that parameter was noop | 14:46 |
| ralonsoh | we have the RBACs and nothing in the API was using this field | 14:46 |
| frickler | was that always the case or did it change some time in the past? | 14:47 |
| ralonsoh | frickler, let me check when that happened | 14:48 |
| frickler | even now doc/source/admin/config-address-scopes.rst is referencing the "--share" option | 14:49 |
| ralonsoh | frickler, since https://review.opendev.org/c/openstack/neutron/+/709122 (2020) | 14:49 |
| ralonsoh | yes, this is a documentation error | 14:49 |
| ralonsoh | we still use some OVO.shared fields | 14:49 |
| ralonsoh | but not in this case | 14:49 |
| ralonsoh | frickler, thanks for the documentation reference | 14:50 |
| ralonsoh | I missed that in the previous patch, I'll push an update | 14:50 |
| opendevreview | Fiorella Yanac proposed x/whitebox-neutron-tempest-plugin master: Add PVLAN test scenario - deactivate/activate pvlan from neutron.conf https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/1008079 | 14:51 |
| frickler | ralonsoh: since https://review.opendev.org/c/openstack/neutron/+/710755/11 seems to be related, has sharing subnet pools via the API also been dropped? or is that planned? | 14:57 |
| ralonsoh | frickler, I'm doing an API/OVO clean-up and I had this in my TODO list | 14:58 |
| ralonsoh | I need to verify that the subnetpool.shared field is no longer used in the code | 14:59 |
| ralonsoh | if that is the case, it will be irrelevant too and we'll need to remove it and update the documentation | 15:00 |
| frickler | well in doc/source/admin/config-rbac.rst the section "How the 'shared' flag relates to these entries" still mentions that that flag can still be used to share these objects with all projects | 15:01 |
| frickler | that includes both scope and address-scope in an explicit list | 15:01 |
| frickler | so to me it is still true that dropping this functionality is a violation of stable API policy | 15:02 |
| frickler | *both subnetpools and address-scope | 15:02 |
| ralonsoh | at least for address-scope this field was not used | 15:03 |
| ralonsoh | I didn't check yet for subnetpool | 15:03 |
| opendevreview | Eduardo Olivares proposed openstack/neutron master: [OVN] Allow router interface ICMP on stateful security groups https://review.opendev.org/c/openstack/neutron/+/1008488 | 15:03 |
| frickler | maybe that was a bug then, that should be fixed, rather than removing a documented feature | 15:05 |
| opendevreview | Merged openstack/os-vif master: trivial: Fix indentation in pyproject.toml https://review.opendev.org/c/openstack/os-vif/+/1008450 | 15:08 |
| ralonsoh | frickler, ok, I'll review all the related patches and provide this info during the next Network meeting | 15:08 |
| frickler | thx, I'll try to do some local testing for my v6 scenario on master too | 15:09 |
| opendevreview | Dmitriy Chubinidze proposed openstack/neutron master: Fix: per-gateway SNAT settings not persisted in multi-gateway routers https://review.opendev.org/c/openstack/neutron/+/971593 | 15:14 |
| ralonsoh | frickler, ok, I'll revert my patch for now | 15:14 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Revert "Drop ``AddressScope.shared`` field" https://review.opendev.org/c/openstack/neutron/+/1008491 | 15:18 |
| opendevreview | Amir Abbas proposed openstack/neutron stable/2026.1: bgp: Fix waiting for port on BGP bridge https://review.opendev.org/c/openstack/neutron/+/1007630 | 16:28 |
| Mike-- | Question related to ovn load balancer health checks for backends. They run on the chassis/node that hosts the backend. If that chassis/host dies the backend stays up potentially forever if the host never comes back. Is this a known limitation? | 19:02 |
| opendevreview | Brian Haley proposed openstack/neutron master: Enable arp_proxy on OVN routers when address scope matches https://review.opendev.org/c/openstack/neutron/+/1008160 | 19:46 |
| opendevreview | Brian Haley proposed openstack/neutron master: Enable arp_proxy on OVN routers when address scope matches https://review.opendev.org/c/openstack/neutron/+/1008160 | 20:00 |
| opendevreview | Brian Haley proposed openstack/neutron-vpnaas master: Validate IPsec Jinja2 templates https://review.opendev.org/c/openstack/neutron-vpnaas/+/1008155 | 20:24 |
| opendevreview | Brian Haley proposed openstack/neutron-vpnaas master: Validate IPsec Jinja2 templates https://review.opendev.org/c/openstack/neutron-vpnaas/+/1008155 | 20:49 |
| opendevreview | Miro Tomaska proposed openstack/neutron master: Add EvpnExecutor for EVPN provisioning https://review.opendev.org/c/openstack/neutron/+/1006431 | 21:21 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: ml2: replace tunnel segment physical_network NULL with '' https://review.opendev.org/c/openstack/neutron/+/1007844 | 22:44 |
| opendevreview | Merged openstack/neutron master: Revert "Drop ``AddressScope.shared`` field" https://review.opendev.org/c/openstack/neutron/+/1008491 | 23:51 |
| opendevreview | Brian Haley proposed openstack/neutron master: Enable arp_proxy on OVN routers when address scope matches https://review.opendev.org/c/openstack/neutron/+/1008160 | 23:58 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!