Tuesday, 2026-05-05

opendevreviewMerged openstack/neutron-lib master: Remove fip64 API definition and documentation  https://review.opendev.org/c/openstack/neutron-lib/+/98674201:03
opendevreviewBrian Haley proposed openstack/neutron master: Change ovn_router_indirect_snat config option to True  https://review.opendev.org/c/openstack/neutron/+/98730804:00
*** ralonsoh is now known as ralonsoh_ooo06:24
opendevreviewEduardo Olivares proposed openstack/neutron master: [OVN] Only set NAT gateway_port when distributed FIP is enabled  https://review.opendev.org/c/openstack/neutron/+/98718706:30
opendevreviewEduardo Olivares proposed openstack/neutron master: Add compute1 node to BGP multinode tempest job  https://review.opendev.org/c/openstack/neutron/+/98607507:23
opendevreviewEduardo Olivares proposed openstack/neutron master: [OVN] Only set NAT gateway_port when distributed FIP is enabled  https://review.opendev.org/c/openstack/neutron/+/98718707:45
opendevreviewMerged openstack/neutron stable/2026.1: Populate OVN AgentCache in the db-sync tool  https://review.opendev.org/c/openstack/neutron/+/98712209:40
opendevreviewLajos Katona proposed openstack/neutron master: Use SDK for Nova notifications  https://review.opendev.org/c/openstack/neutron/+/98390510:20
opendevreviewHarald Jensås proposed openstack/neutron master: ML2: tri-state checks for vlan_transparent/qinq  https://review.opendev.org/c/openstack/neutron/+/98733411:03
tafkamaxHi!11:25
tafkamaxWhat are the thoughts on this patch? https://review.opendev.org/c/openstack/neutron/+/98634911:26
opendevreviewHarald Jensås proposed openstack/neutron-lib master: Document ML2 VLAN tri-state capability behavior  https://review.opendev.org/c/openstack/neutron-lib/+/98733711:26
tafkamaxnudging it along for my own benefit aswell :)11:27
tafkamaxi know everybody has work to do...11:27
lajoskatonatafkamax: Hi, you can try to ping ralonsoh here (perhaps He is on PTO) or try to bring this topic to the team meetings On-Demand agenda this afternoon (the meeting is from 1300UTC and the on-demand part is the last one, so around end-of-the-hour)11:40
tafkamaxok, will try to be online then, thx11:41
opendevreviewyatin proposed openstack/neutron master: [service-type] Clear warnings for using ServicePluginBase  https://review.opendev.org/c/openstack/neutron/+/98734912:36
haleyb#startmeeting networking13:00
opendevmeetMeeting started Tue May  5 13:00:34 2026 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.13:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.13:00
opendevmeetThe meeting name has been set to 'networking'13:00
haleybPing list: bcafarel, elvira, frickler, mlavalle, mtomaska, slaweq, ykarel, lajoskatona, jlibosva, haleyb, ralonsoh13:00
mlavalle\o13:00
ykarelo/13:01
slaweqo/13:01
lajoskatonao/13:02
haleybalright, we have quorum13:02
haleyb#topic announcements13:02
haleybWe are currently in Week R-21 of Hibiscus13:02
haleyb#link https://releases.openstack.org/hibiscus/schedule.html13:02
bcafarellate o/13:02
haleybHibiscus-1 milestone is next week13:03
haleybso hopefully we can get some good early changes merged that need some soaking13:04
haleyb2024.2/Dalmatian transitioned to EOL, still trying to get our n-t-p jobs cleaned-up and remove traces of them13:05
opendevreviewJakub Libosvar proposed openstack/neutron-lib master: evpn: Do not set evpn_vni to None by default  https://review.opendev.org/c/openstack/neutron-lib/+/98735413:06
haleybi actually split into two pieces, was just looking for first part13:06
haleyb#link https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/98696413:06
haleybthe n-d-r jobs are randomly failing still13:06
haleybJust a reminder to use the priority dashboard for anything neutron/networking related13:08
haleyb#link https://tinyurl.com/59z278km13:08
haleybRP +1 for "ready to merge" changes, RP +2 for gate blockers and similar13:08
lajoskatonathe n-d-r failures are on master?13:08
haleyblajoskatona: randomly on master, 2025.2 and 2025.113:08
lajoskatonaohhh, nice13:08
haleybresource_setup_container ? i think that's CI ?13:09
lajoskatonahttps://codesearch.openstack.org/?q=resource_setup_container&i=nope&literal=nope&files=&excludeFiles=&repos=13:10
opendevreviewJakub Libosvar proposed openstack/neutron-tempest-plugin master: evpn: Add API router tests for EVPN extension  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/98735513:10
haleybi mean, it could be something else, os-ken is in there as well, but just a single test failure13:10
lajoskatonaseems like smething for the tempest tests for dynamic-routing13:10
lajoskatonayeah, os-ken is everywhere, and can be a good suspect13:11
ykarelin that test some docker setup was done, so coule be related to that13:12
haleybos_ken.tests.integrated.common.docker_base.CommandError13:12
ykarelok confirmed in logs, it's related to that13:13
ykarelERROR: failed to build: failed to solve: process "/bin/sh -c apt-get install -qy --no-install-recommends telnet tcpdump quagga-bgpd" did not complete successfully: exit code: 10013:13
ykarel: os_ken.tests.integrated.common.docker_base.CommandError13:13
ykarelfrom https://564427108cabbad8b493-532d928235cdca0f1f7d2e9417dacd2f.ssl.cf1.rackcdn.com/openstack/8007a1732cc04596ae093d964dac1538/controller/logs/tempest_log.txt13:13
haleybso trying to build the quagga con tainer fails13:13
haleyboh, could be related to the ubuntu mirrors perhaps?13:14
ykarelit's not using CI mirrors, which should have avoided/limited such issues related to external acceess13:14
ykarelso let's have a bug and fix it like ^ ?13:15
haleybykarel: yes, we should open a bug then, error 100 is the generic error from apt but maybe we can narrow it down13:16
ykarel+1 , will you open the bug or want me to do that?13:17
haleybAI says to change to apt-get update && apt-get install13:17
ykarelthat's not true here :)13:17
haleybykarel: can you do that while i type away13:17
ykarelok will do13:18
haleybykarel: and i don't know if that's the issue, i'd assume an apt-get update was run at some point13:18
ykarel#5 308.2 W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/InRelease  Connection failed [IP: 91.189.92.23 80]13:18
ykarel#5 308.2 W: Some index files failed to download. They have been ignored, or old ones used instead.13:18
ykarelso we should avoid these external mirrors and instead use ci mirrors and that should help here13:19
haleybi think we are still having issues after a ddos attack last week13:19
haleybbut yes, maybe there is some change we can make13:20
haleybalright will continue13:21
haleybi will be traveling next week, so will have limited time for neutron (and irc)13:22
haleybcan someone lead this meeting next week? and possibly drivers if there is an agenda?13:22
ykarelreported https://bugs.launchpad.net/neutron/+bug/215119413:23
haleybi didn't plan for it to be H-1, so slaweq you will need to do the release approval when those patches drop if you don't see me around13:24
ykarelalso i see it's using focal, so may be can also consider moving to newer versions13:24
haleybykarel: ack, thanks!13:24
slaweqsure13:24
haleybykarel: oh, everything should be jammy or noble, maybe theres a definition issue, don't know if it will help13:25
ykarelhaleyb, its about that container image which being built in the jobs, we should have all our jobs in jammy/noble already13:25
haleybright13:26
haleybok, so any taker for running this meeting next week? or everyone can draw straws? :)13:27
haleybalright, i'll assume as a collective someone will take over13:28
slaweqI can run it next week if there is no other volunteers13:28
lajoskatonaI can :-)13:28
lajoskatonaOhh, slaweq was quicker :-)13:29
haleybslaweq, lajoskatona: thanks, was going to do eenie minee moe13:29
slaweqLOL13:29
haleybalright, i think we can move onto bugs13:30
haleyb#topic bugs13:30
haleybykarel was the deputy, his email is at13:30
haleyb#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/X4BCDF75GJBZBDU4ZQZ6YWULKPFIUR7E/13:30
haleyball the high/med/low have owners, don't know about patches13:31
haleyb#link https://bugs.launchpad.net/neutron/+bug/215068213:32
haleyb[ovn-octavia-provider] VIP ports are unprotected: empty device_id allows them to be attached to other workloads, breaking the LB13:32
haleyb#link https://review.opendev.org/c/openstack/ovn-octavia-provider/+/98673013:32
haleybthat just needs a review13:33
haleybis froyo around?13:33
haleyboh, i see he approved something yesterday so that's the answer13:35
froyoyeah!13:35
froyohaleyb, I will take a look there13:35
haleybfroyo: hi! can you take a look at that one? i'm sure a lot of AI generation but looks ok13:35
haleybthanks13:35
froyoyw13:36
haleybnext one13:36
haleyb#link https://bugs.launchpad.net/neutron/+bug/215086413:36
haleybnetworking-sfc unit tests are failing with filtervalidation extension enabled13:36
haleyblajoskatona: you asked me about this yesterday13:36
lajoskatonayes13:37
lajoskatonaI will push the sfc patch to make the gate happy13:37
haleybgreat, thanks13:37
lajoskatonaand after that I will reopen the patch to move sfc api definitions to n-lib13:37
lajoskatonaactually to use the definitions from n-lib13:38
haleyblajoskatona: right, you mentioned the abandoned changes13:38
lajoskatonathis one: https://review.opendev.org/c/openstack/networking-sfc/+/55381913:38
haleyblast high priority bug is13:39
haleyb#link https://bugs.launchpad.net/neutron/+bug/215086613:39
haleybconnectivity lost with FIP after ovn-controller restarted13:39
haleyblajoskatona: yes, right13:39
haleyboh, that's really old13:39
haleybregarding the ovn-controller one, there is a patch up13:40
haleyb#link https://review.opendev.org/c/openstack/neutron/+/98718713:40
haleybthat was from Eduardo13:40
haleyband i'll skip to the unassigned list of bugs13:42
haleyb#link https://bugs.launchpad.net/neutron/+bug/215087913:42
haleybOVN BGP Agent missing egress from ip rules and default gateway route in br-ex table13:42
haleybkuba confirmed the bug looks legit, don't know if submittor will work on it13:43
haleybso if someone wants an ovn-bgp-agent bug it's available :)13:43
haleyband the last unassigned one13:44
haleyb#link https://bugs.launchpad.net/neutron/+bug/215075413:44
haleybresource_request used only for QoS, cannot be used for physnet scheduling13:44
haleybralonsoh had asked some questions, awaiting answers13:44
lajoskatonabaremetal is for ironinc, am I wrong?13:45
haleybok, any other bugs to discuss?13:45
haleyblajoskatona: right, that would explain why i think cardoe responded to a ping from nate in channel? or i at least thought he did?13:47
haleybi lost some of my scrollback13:47
haleybor maybe it was on the ML13:48
lajoskatonaack, so perhaps this is again some Ironic-Neutron x-project (+Nova/placement) thing :-)13:48
haleybmaybe, yes13:49
cardoeoh dang I'm here now.13:49
haleybah yes, it was in a response to the drivers meeting last week13:50
cardoeI'm happy to discuss it at a drivers meeting.13:50
haleybcardoe: yeah, we were just discussing a bug that i think you responded to on the ML from Nate Harper?13:50
cardoeYes. So it actually relates to a question I think I asked at the PTG.13:51
haleybcardoe: yes, we can talk about it then (friday)13:51
cardoeIt's about use case and visibility of resources.13:51
cardoeThe model with VMs treats everything as uniform and the only difference is bandwidth maybe which the QoS support for resource_request does.13:52
cardoeThere's a common thread through all of this.13:52
cardoeAnd that's having some understanding of what you're built on to make the right connection choices.13:53
cardoeLike Helen's type-5 spec. Say you want to build a box in one room vs another room in the future.13:53
cardoeSince that spec is letting you bridge rooms together with OVN.13:53
cardoeYes bandwidth is something you can quantify those two rooms... but it's not necessarily correct.13:54
haleybcardoe: ack, we can loop back friday, or in a few minutes, sorry i have to wrap-up the meeting13:55
haleybbut thanks for responding and the ML response, you know more about this space than all of us :)13:55
haleybok, 5 minutes left, can go through the rest quickly13:56
haleyb#topic specs13:56
haleyb#link https://review.opendev.org/q/project:openstack/neutron-specs+status:open13:56
haleybthe type-5 spec was merged :)13:56
haleybthere is at least one in the list ready for review (security default statefulness)13:57
haleybcardoe: did you want to go forward with https://review.opendev.org/c/openstack/neutron-specs/+/952166 ?13:57
haleybhard to tell based on last comment13:57
haleybfeel free to respond in the spec review as well13:58
haleyband on the topic of specs13:58
haleybReminder: If you have a topic for the drivers meeting on Friday, please add it to the wiki @ https://wiki.openstack.org/wiki/Meetings/NeutronDrivers13:58
haleyb#link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers13:58
haleybok, 2 minutes13:59
cardoeHonestly I'd love to just remove the restriction on vxlan to allow a physical_network13:59
haleybcardoe: maybe something else to discuss friday13:59
haleyb#topic community goals13:59
haleyb#link https://review.opendev.org/q/topic:%22sdk_for_neutron%2213:59
haleyb#link https://review.opendev.org/q/topic:%2522migrate_stadium_osc%252214:00
lajoskatonaslow progress with both, for nova patches I wait for review14:00
haleybright, i think some of the OSC patches have merged though14:01
lajoskatonayes, and for bgpvpn there's also a +214:01
haleybmaybe only cleanup is https://review.opendev.org/c/openstack/python-neutronclient/+/977975 ?14:01
haleybok, need to wrap up14:02
haleyb#topic on-demand14:02
haleybanything else to discuss?14:02
lajoskatonanothing from me14:03
haleybokay, as we're over i'll let everyone go14:03
haleybthanks for attending and have a good week!14:03
haleyb#endmeeting14:03
opendevmeetMeeting ended Tue May  5 14:03:24 2026 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:03
opendevmeetMinutes:        https://meetings.opendev.org/meetings/networking/2026/networking.2026-05-05-13.00.html14:03
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/networking/2026/networking.2026-05-05-13.00.txt14:03
opendevmeetLog:            https://meetings.opendev.org/meetings/networking/2026/networking.2026-05-05-13.00.log.html14:03
mlavalle\o14:03
lajoskatonao/14:03
ykarelo/14:03
tafkamaxI was late14:06
tafkamaxBut nudging along this14:06
tafkamaxhttps://review.opendev.org/c/openstack/neutron/+/98634914:06
cardoehaleyb: I'm happy to help in any way I can. I'll admit my $TIME has been lower than I wanted but the network tooling is important to me.14:09
opendevreviewLajos Katona proposed openstack/networking-sfc master: Enable name as filter for SFC API  https://review.opendev.org/c/openstack/networking-sfc/+/98737114:40
opendevreviewMerged openstack/ovn-octavia-provider master: Add support for Python 3.13  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/98290814:40
opendevreviewBrian Haley proposed openstack/neutron master: Change ovn_router_indirect_snat config option to True  https://review.opendev.org/c/openstack/neutron/+/98730814:50
haleybcardoe: ack, sorry was in downstream meeting14:51
cardoeno worries14:51
cardoeI was thinking about making an extension that added a "fabric" field to network. Which could then be used for scheduling.14:53
cardoeLike during one of the calls Rodolfo mentioned that VXLAN is an overlay network and it's assumed that everything is connected together in one VRF.14:54
opendevreviewLajos Katona proposed openstack/neutron-lib master: sfc: make name fields filter in API  https://review.opendev.org/c/openstack/neutron-lib/+/98737214:54
cardoeBut we're seeing asks around multiple VRFs (the type-5 spec for example is adding extra VRFs via config file and then creating pools of VNIs separately)14:54
stephenfinhaleyb: RE: your type hint questions, it's all been hand-written [*] so far 😅 I've repeatedly experimented with claude and different models, but found it kept trying to "cheat" with `type: ignore` statements or excessive use of `typing.Any`14:55
cardoeWe can continue to treat VXLAN and OVN as an overlay when physical_network = None14:55
cardoeOtherwise the fabric can field can interact with physical_network.14:55
haleybstephenfin: impressive, so i guess there is no easy way out for neutron* repos, maybe someone will have the time eventually14:57
* haleyb is not asking you to do anything btw, but maybe i'll spend some tokens to see how claude does14:58
stephenfinI mean, perhaps someone can drive an agent better that I have, and the fact that a lot of the depdency libraries are now typed should help (since you can verify its output)14:58
stephenfin...but the "don't cheat" bit was the hardest one to enforce. It just kept ignoring me 😅14:59
stephenfinWholly unrelated: the networking-extra job in SDK appears to be permafailing since this time last week https://zuul.opendev.org/t/openstack/builds?job_name=openstacksdk-functional-devstack-networking-ext&project=openstack/openstacksdk15:00
stephenfinLooking at the jobs, it seems to be a bug in fwaas https://zuul.opendev.org/t/openstack/build/89bace86508a43b7833ba9f0b9588484 Did the API suddenly get stricter there?15:01
stephenfinAh, looks like this was ralonsoh https://review.opendev.org/c/openstack/neutron/+/97846315:07
haleybstephenfin: yes, was just looking for that one, it broke a couple of repos15:08
haleyband i'm not good at driving AI either, i can say it doesn't listen but it would say i didn't explain well enough15:08
stephenfinhaleyb: the resource currently says `name` is a valid filter but the error says that's not true https://github.com/openstack/openstacksdk/blob/master/openstack/network/v2/firewall_policy.py#L3815:11
haleyblajoskatona: seems fwaas is broken same way networking-sfc is ^^^ ?15:11
haleybstephenfin: we'll have to take a look15:11
stephenfiniiuc, the API "spec" lives here https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/firewall_v2.py I'm not sure how to read that to figure out what the expected filters are though15:12
stephenfinunderstood. Does it make sense to (a) drop the filters or (b) make the job non-voting for now?15:12
stephenfin...given there's a few things backed up behind this now15:12
haleybstephenfin: https://review.opendev.org/c/openstack/neutron-lib/+/987372 is fixing it for sfc, probably need similar for firewall_v215:13
haleybstephenfin: is that a job in openstacksdk?15:13
stephenfinyes https://zuul.opendev.org/t/openstack/builds?job_name=openstacksdk-functional-devstack-networking-ext&project=openstack/openstacksdk15:13
stephenfinmaster is currently rather unhappy as a result https://review.opendev.org/q/project:openstack/openstacksdk+branch:master+is:open15:14
haleybguess we could make non-voting until we release a new neutron-lib with fixes, vpnaas probably broken as well15:15
stephenfinack https://review.opendev.org/c/openstack/openstacksdk/+/98737415:24
lajoskatonahaleyb, stephenfin: anything can happen, strange that our weekly periodic was green, and only sfc failed15:39
lajoskatonaIt was strange for me, but liked the idea that we have such robust software :-)15:40
opendevreviewBrian Haley proposed openstack/neutron-lib master: Update definitions to support name field filter  https://review.opendev.org/c/openstack/neutron-lib/+/98737815:51
haleyblajoskatona: think that will help, untested15:51
haleybwe do have an experimental job in neutron for openstacksdk-functional-devstack-networking that could maybe catch it?15:53
opendevreviewBrian Haley proposed openstack/neutron master: DNM: Test name field filtering changes with sdk  https://review.opendev.org/c/openstack/neutron/+/98738115:56
stephenfinhaleyb: lajoskatona: I'm just cross-referencing the SDK definitions with what's in neutron-lib and I see a few other differences. Who would be the best person to say whether it's SDK or neutron-lib that is wrong for each?16:31
stephenfinFor example, firewall groups. SDK: https://github.com/openstack/openstacksdk/blob/master/openstack/network/v2/firewall_group.py#L33-L42; neutron-lib: https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/firewall_v2.py#L107-L15016:32
stephenfinWe're fixing name but apparently description, egress_firewall_policy_id, ingress_firewall_policy_id, shared, status and ports are all missing `is_filter`, while project_id is missing entirely16:35
haleybstephenfin: i think that will be addressed with https://review.opendev.org/c/openstack/neutron-lib/+/987378 - i'm testing in https://review.opendev.org/c/openstack/neutron/+/98738116:35
haleybif i'm understanding correctly16:35
stephenfinThat's only adding name though? Do we need to add `is_filter` to e.g. `ingress_firewall_policy_id` also?16:36
stephenfinBasically are there any other valid filters _except_ for name?16:36
haleybstephenfin: i'd have to look16:37
stephenfinAck. If not, we need to drop everything else from the `_query_mapping` fields in the various fwaas resources16:37
haleybi mean, for things like subnets you can filter on anything pretty much16:41
haleybi was shooting for the quick hit to make the gates green16:41
stephenfinfari16:46
stephenfin*fair16:46
stephenfinI left a comment on the change but, as noted there, didn't -1 since this can all be done separately. Hopefully the links are useful at least.16:47
haleybthe api-ref does say "The Networking API v2.0 supports filtering based on all top level attributes of a resource. Filters are applicable to all list requests."16:54
haleybi do see a lot of these recently migrated to OSC aren't very feature-rich in that filter department16:54
haleybi actually need to add the -ext job to my test patch17:02
cardoehaleyb: https://review.opendev.org/c/openstack/neutron/+/985837 is the change for allowing vxlan to take physical_network for example.17:32
opendevreviewMerged openstack/neutron master: bgp: Update main router policies when chassis is added  https://review.opendev.org/c/openstack/neutron/+/98589517:43
opendevreviewBrian Haley proposed openstack/neutron-lib master: Update definitions to support name field filter  https://review.opendev.org/c/openstack/neutron-lib/+/98737818:15
opendevreviewBrian Haley proposed openstack/neutron master: DNM: Test name field filtering changes with sdk  https://review.opendev.org/c/openstack/neutron/+/98738118:16
haleybcardoe: i just posted some more comments there18:30
cardoehaleyb: thanks! I've also added a topic to the drivers meeting. Hopefully correctly this time.18:32
haleybcardoe: ack, it's in the section where i'll notice it now I have selective eyesight :)18:34
cardoehaleyb: so I've got a crazy vision for where neutron controls the underlay and all the BGP bits as well as the overlay that the VMs connect to.18:56
cardoeI think I've got most of the pieces together.18:56
cardoeI just want to make sure I present things properly.18:56
opendevreviewJakub Libosvar proposed openstack/neutron-tempest-plugin master: evpn: Add API router tests for EVPN extension  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/98735519:58
*** kleini_ is now known as kleini20:33
opendevreviewBrian Haley proposed openstack/neutron master: WIP: Stop using neutron-lib project info code  https://review.opendev.org/c/openstack/neutron/+/98696120:37
cardoehaleyb: ugh you made me panic that somehow neutron wasn't doing project_id enforcement21:40
cardoeon the VXLAN type21:40
haleybno, just wondering about the filters there based on existing code21:42
cardoeyeah that's what I meant21:42
cardoeI do need to tweak something. But there's duplication.21:43
cardoehttps://opendev.org/openstack/neutron/src/commit/f95a2c61393b59a6bc2fb67323c31d7e7ca8af13/neutron/plugins/ml2/drivers/type_vlan.py#L24221:46
cardoebecause of that line we need to build up the dict again while the other paths can use what's supplied.21:46
opendevreviewDoug Goldstein proposed openstack/neutron-lib master: remove reference to non-existent method  https://review.opendev.org/c/openstack/neutron-lib/+/98743722:12
opendevreviewBrian Haley proposed openstack/neutron-tempest-plugin master: Remove target_tenant from RBAC calls  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/98743822:24

Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!