Hi Stackers, Thanks to everyone that participated in the Neutron sessions last week, I think we covered a lot of topics and agreed on actions for most of them. All notes and discussions can be found on the Etherpad at https://etherpad.opendev.org/p/apr2026-ptg-neutron Below is a summary of the outcomes of the various topics, thanks to Rodolfo for a lot of this. -Brian Gazpacho Retrospective ====================== Good: Strong feature release in 2026.1 (https://github.com/openstack/releases/blob/master/deliverables/gazpacho/neut...) Progress on the long-running tenant_id removal effort. Bad: The OVS agent and os-ken still run with eventlet, despite a migration patch (966613), the migration is not fully complete. Action: to open a bug summarizing the current state of eventlet usage in ovs-agent and os-ken, and explore alternatives (e.g., reverting to vsctl). To be improved: Community traction/enlargement remains a recurring concern. Attracting new core reviewers and bug fixers is difficult, though the contributor base is at least stable. AI tools are starting to be used in the project -- e.g., experimenting with migrating fullstack tests to tempest using LLM assistance. Functional job duration is a pain point. MySQL performance is particularly problematic. Open bug: LP#2136827. Eventlet Deprecation Cleanup ============================ Several tests were marked as "skipped" during the eventlet deprecation. This recently triggered a pylint W0101 (unreachable code) failure in the pep8 job. Action: to file a bug for undoing the skips. About ~20 files need an owner to review. Some skips can simply be removed. Some require code refactoring. Fullstack test files: Decision is to remove them, since they should be migrated to other frameworks (neutron-tempest-plugin, whitebox-neutron-tempest-plugin, tobiko). The original tests can always be referenced in git history. Migration tracking: LP#2115327. The core blocker for functional OVS agent tests is os-ken -- it's the only reason the OVS agent can't be spawned in a separate thread for testing. tenant_id to project_id Migration Update ======================================== Blueprint: https://blueprints.launchpad.net/neutron/+spec/keystone-v3 This cycle's plan: Work on sub-projects (neutron-fwaas, neutron-vpnaas, ovn-octavia-provider, networking-bgpvpn, etc.). Plan to use Claude or similar LLM for wholesale string replacement given the smaller codebases. Start removing compatibility code from neutron-lib: 982599 (remove tenant_id from context object). Future ("I"-cycle) work: Remove additional code in TODO comments from neutron. Callers passing only tenant_id will start failing. Open questions: Can the API definitions themselves be changed? RBAC implications? Should a lint check for tenant_id be added? Need to consider whether the final switch happens in a SLURP or non-SLURP release per the release cadence adjustment. Historical note: tenant_id was deprecated 9 years ago but kept for backwards compatibility. LLM AI Assistant in Neutron Repository ====================================== The goal is to match the community guidelines to include several skills (and knowledge and persona) definitions to execute common actions (code reviews) and automate programatic actions (stable CI jobs creation during the new release branch creation, DB branch creation, Python version update, OVO compatibility removal, requirements bump, etc). Ironic Cross-Project Session ============================ 1) ML2 Emergency Stop on Binding Failures Problem: ML2 currently catches exceptions broadly during port binding (managers.py L961-964). For baremetal, drivers can detect that a binding will never succeed (e.g., out of dynamic segments, bad configuration) but have no way to abort binding entirely. Discussion: This applies to both hierarchical port binding (HPB) and non-HPB (VLAN type) cases. rubasov initially thought it was HPB-only, but TheJulia clarified it affects any case where substrate infrastructure issues are detectable. Outcome: Treat as a bug/RFE. TheJulia will submit a bug and fix. Related: LP#2146467. 2) VLAN Transparency for Baremetal Problem: Concerns about VLAN transparency behavior with baremetal (LP#2131664). The code at managers.py L462 should recognize None as "not supported" (True/False). Outcome: Hjensas will take a look at this. 3) ML2 Driver Order on Port Deletion Problem: Edge cases with HPB cleanup where the execution order of drivers during destructive operations (port deletion) doesn't allow proper config unwinding. Outcome: Hjensas will create/link a bug. Consensus is this is an RFE-worthy bug -- reversing execution order for destructive activities may be the right solution. 4) EVPN Spec and Scheduling Reported scheduling issue relates to the EVPN spec under review. Higher-level scheduling discussion (network modeling, upfront choice) is needed but deferred. LFX Insights and Core Reviewer Updates ====================================== LFX Insights (https://insights.linuxfoundation.org/project/OpenStack/repository-group/neut...) and Stackalytics (https://www.stackalytics.io/report/contribution?module=neutron-group&project...) show Neutron is doing OK for contributions overall. But contributions are concentrated: 3 contributors account for 52% of all contributions.Sub-projects (neutron-fwaas, vpnaas, ovn-bgp-agent) are even more skewed -- 2 contributors often make 53%+ of contributions. Proposed solutions: Add core reviewers to sub-projects from people who have domain expertise, even if they lack core reviewer experience. They could give good feedback and test patches. A model similar to SDK: some members get +2 rights but not Workflow+1. Nova has been discussing a 2-level core reviewer group (mailing list thread). Concrete action: Miro agreed to become core for tap-as-a-service. slaweq may take care of FWaaS (at least the OVN part). haleyb will reach out to largest contributors in other areas. [RFE] Allow Configuring Default SG Statefulness =============================================== RFE: LP#2146803. Patch: 982557. Spec: 984350. Proposal: Add an API extension and CLI commands: openstack security group default [stateful/stateless] [--all-projects/--project] Admin-only by default; project owners could optionally set it for their own projects. The --all-projects value serves as the system-wide default. A per-project override takes precedence. [RFE] Allow Rebalancing of OVN LRPs =================================== RFE: LP#2096704. Spec: 982743. Alternative proposal patch: 983161. Open question: Is the re-balancing tool (983161) still needed if the patches at topic:bug/2103521 are implemented? No in U/S; these patches may provide automatic re-balancing, potentially making an explicit tool redundant. [RFE] Multiple Non-Contiguous Ports in SG Rules for ML2/OVN =========================================================== RFE: LP#2147189. Leverages OVN ACL syntax: tcp.dst == {80, 443} || tcp.dst >= 500 && tcp.dst <= 600. Aligns with GCP/Azure multi-port support. Backend-specific: ML2/OVN would use native syntax; other backends (ML2/OVS) would expand to multiple rules. Discussion points: How to store in the DB: single register with expansion on non-supporting backends? New tables (securitygrouprule_ranges, securitygrouprule_ports)? A new "port group" resource similar to address groups? Storing the port groups as a string in a single SG rule register is a violation of the normal forms rules to design a DB. Action: kyu0 to propose a spec detailing user issues (handling thousands of SG rules) and discuss implementation details there. [RFE] L3 Agent Scheduler API Support in ML2/OVN =============================================== Spec: 982743. Already discussed 2 PTGs ago. Near 100% match with the OVS L3 agents API. The only difference is a new extension: neutron-lib 982781. In ML2/OVN, chassis priority must be explicitly defined (no VRRP between router instances). Open question: If chassis priorities prio_1, prio_2, prio_3 exist and a new chassis is added with prio_2, should this be prevented (duplicate)? Or should existing priorities be reorganized? Conclusion defined and approved in the merged spec. [RFE] BGP EVPN Type-5 Advertisement =================================== Spec: 982256 Resolved comments/decisions: Configuration: A new [ovn_bgp] section will be added to both ml2_ovn.ini and ovn_agent.ini for EVPN configurations. REST API: openstack router create --evpn-vni [VNI] -- latest patch uses consistent typing. Subnet advertisement: Uses openstack router add subnet --advertise-host (not openstack network create --advertise). No issues raised. No EVPN flavor router: Decided a flavor router is overkill. The OVN driver behavior related to the router should not change; keep the existing OVN driver implementation. VNI range separation: OVN expects two different VXLAN tunnels -- one for east-west traffic and one for EVPN using external-ids:ovn-evpn-local-ip=$vtep_ip. So there are two separate VNI spaces (no conflict). CRUD operations: Only create is supported for now (openstack router set/unset --evpn-vni is deferred). Treat it like VLAN -- changing EVPN configuration has side-effects in routing tables, so changes are disallowed. Service plugin agnosticism: The service plugin side is routing protocol suite agnostic. Stated explicitly in the spec. Open RFEs Discussion ==================== LP#2147305: Neutron cannot handle forks due to ovsdbapp. Not formally an RFE but behaves like one. Previously discussed in a team meeting. Action: ralonsoh will look at this next week, with help from Terry and others. Open specs review (all open neutron-specs): 952166 -- Will ask Julia about abandoning (mentioned in spec itself). 965946 (project-specific QoS controls) -- Will ping slaweq for review. 983896 -- Not a spec, just cleanup. 936063 (NFS-Ganesha extension in OVN Agent) -- haleyb will add comment asking if still being worked on. neutronclient Work ================== What it is: Update on migrating neutronclient functionality to SDK and OSC (lajoskatona). Two tracks: Move neutronclient calls to SDK -- Recent work focused on Nova: topic:sdk_for_neutron. Plan to cover all Nova calls for early Hibiscus (26.2). Migrate OSC plugin code to python-openstackclient -- topic:migrate_stadium_osc. stephenfin clarified the general policy: legacy client commands that don't belong in OSC are (a) service-only API commands, (b) meta commands replaceable by bash scripting, (c) commands for already-deprecated APIs. Everything else is fair game for migration. Stadium Dashboards ================== Affected dashboards: networking-bgpvpn, neutron-fwaas-dashboard, neutron-vpnaas-dashboard all depend on Horizon code that the Horizon team plans to refactor (mailing list thread). Open questions: Are there actual users of these dashboards? If yes, do we need extra CI jobs to test Horizon refactoring impact? haleyb noted that Canonical only ships the vpnaas dashboard; will check usage. Action: lajoskatona will investigate the impact of Horizon refactoring on these dashboards. Post Quantum OpenStack ====================== Wiki: https://wiki.openstack.org/wiki/Post_quantum_openstack Will also be discussed in the TC room on Friday. Question: Should Neutron have a CI job to ensure post-quantum compliance? Current status: Neutron appears to be in good shape based on tests Miro conducted a few weeks ago.