Current Series Release Notes

29.0.0.0rc1-121

New Features

  • The DHCP agent now reports the number of network, subnet and port updates waiting to be processed as pending_updates in its configurations, shown by openstack network agent show, as the L3 agent does. A value that stays high or keeps growing means the agent is not keeping up with its work.

  • The L3 agent now reports the number of router and network updates waiting to be processed as pending_updates in its configurations, shown by openstack network agent show. A value that stays high or keeps growing means the agent is not keeping up with its work.

  • Added support for the OpenTelemetry tracing middleware provided by oslo.middleware. The middleware is wired into the Neutron API paste pipeline and is disabled by default, acting as a zero-overhead passthrough when off. To enable distributed tracing, set enabled = True under the [oslo_middleware_tracing] group in neutron.conf and install the optional OpenTelemetry packages.

Upgrade Notes

  • Setting the trusted key directly in a port’s binding:profile, which was deprecated in 2024.2, is no longer allowed. The dedicated port attribute trusted, added by the API extension port_trusted_vif should be used instead.

  • [ML2/OVN] Deployments affected by bug 2162974 can already have duplicated Logical_Switch registers. This patch prevents the creation of new duplicates but does not remove the existing ones. Check for registers sharing the same neutron-<network_id> name and delete the one that has no router port and no ovn-metadata port.

  • Neutron no longer reads or writes the four ML2 segment allocation tables (ml2_vlan_allocations, ml2_vxlan_allocations, ml2_gre_allocations, and ml2_geneve_allocations). These tables are deprecated: free segmentation IDs are chosen from configured ranges (neutron.conf or the network_segment_range service plugin) and IDs already in use are taken from the networksegments table, including enforcement by the (network_type, physical_network, segmentation_id) UNIQUE constraint added in the preceding database migration. The legacy allocation tables remain in the database until a future contract migration removes them.

  • Neutron now refuses to start when [ml2_type_vlan] network_vlan_ranges no longer covers a VLAN ID that a network segment still holds, either because a range was narrowed or because a physical network was dropped from it. The error names the physical networks and VLAN IDs involved. Restore the ranges in the configuration file, or delete the networks holding those VLAN IDs, to start again. Network segment ranges created through the API are not affected: their allocated registers are kept and Neutron starts normally, since an administrator could not otherwise reach the API to undo such a change.

  • Tunnel type segments (VxLAN, GRE, Geneve) now store physical_network = '' (empty string) instead of NULL in the networksegments table. An expand migration converts existing NULL values automatically and adds a UNIQUE constraint on (network_type, physical_network, segmentation_id), which prevents duplicate segment allocations at the database level for VLAN and tunnel types.

  • If the database contains corrupt duplicate tunnel segments (the same network_id, network_type, and segment_index with physical_network = NULL), the migration will fail and the operator must resolve the duplicates manually. The networksegments_unique_constraint_check entry in neutron-status upgrade check detects this condition before the migration runs.

  • The ML2 plugin no longer supports type drivers that inherit from the legacy TypeDriver base class. All type drivers must now inherit from ML2TypeDriver, which receives a Neutron context object instead of a raw SQLAlchemy session. A startup validation has been added to TypeManager._register_types() that rejects any type driver not inheriting from ML2TypeDriver, raising a clear error instead of a runtime crash. All in-tree type drivers already use ML2TypeDriver; only out-of-tree drivers that still inherit from the old TypeDriver class are affected.

  • The standalone OVN Metadata agent (neutron-ovn-metadata-agent) has been removed. It was deprecated in 2025.2 in favor of the OVN agent with the “metadata” plugable extension enabled. To migrate, stop the OVN Metadata agent and start the OVN agent (neutron-ovn-agent) with the metadata extension enabled in the configuration file (extensions = metadata in the [DEFAULT] section). The rest of the configuration is the same; the new agent can reuse the old configuration files.

  • The configuration options [ovn]ovs_create_tap and [OVS_DRIVER]ovs_create_tap are removed. Neutron always sets ovs_create_tap: True in the port vif_details for kernel OVS ports, enabling os-vif TAP pre-creation during live migration. Remove these options from neutron.conf if present.

  • The default delete_port policy now denies deletion of ports with device_owner network:distributed, such as the OVN metadata port, unless the caller is an admin, a service user, or a project member or network owner whose request also carries a service token. A new helper rule distributed_device was added. Deployments with customized policy files should review and update delete_port if they rely on the previous behaviour.

Security Issues

  • Non-admin users can no longer create or update RBAC policies with the access_as_external action via the API. The new create_rbac_policy:action and update_rbac_policy:action policy rules restrict that action to cloud administrators by default, matching the existing plugin check that only admins may promote a network to external. For more information, see bug 2161501.

Bug Fixes

  • The OVS trunk service driver now removes stale tpi- and spi- patch ports from the integration bridge at agent startup when their peer on the trunk bridge no longer exists (i.e. the trunk bridge was already deleted). This can happen after a compute host crash and VM evacuation, where the source host never ran its trunk teardown.

  • Fixed the ML2/OVS agent on the source host sending a spurious network-vif-plugged event during live migration. When the source agent received a port_update for the new INACTIVE binding on the destination host, it can happen that the agent re-processes the migrating port and calls update_device_up(), making Nova beleive the port is ready for traffic on the destination. The source agent now detects that a port is being migrated to another host (either from the binding profile or, as a fallback, from an INACTIVE binding on a different host) and skips processing it. See bug: 2162710.

  • ML2 mechanism drivers can now raise the existing neutron_lib.exceptions.PortBindingError from bind_port() when binding cannot safely continue. ML2 stops trying other mechanism drivers, including at higher levels of hierarchical binding, clears partial binding state, and records binding_failed. Other exceptions continue to be logged and ignored so later drivers may bind the port. [bug 2149843]

  • [ML2/OVN] Without OVS 3.1.0 (commit 55b9507) the Logical_Switch UUID is not persisted and does not match the Neutron network ID; such register, as any register created before that, is only identifiable by its neutron-<network_id> name. Two code paths still resolved it by register UUID: the maintenance task, that passes the Neutron network ID to get_lswitch, and AddNetworkCommand. Both missed such a register and created a second one with the same name. Since the Logical_Switch table has no index in the OVN_Northbound schema, ovsdb-server accepts the duplicated register; the ports created afterwards are resolved by name and land on any of them, and those landing on the duplicated one have neither router port nor metadata port. Both code paths now fall back to a lookup by name. For more information, see bug 2162974.

  • Fixed an issue in the OVN trunk driver where trunks were incorrectly managed for parent ports with type=external (e.g., baremetal/SR-IOV ports). The driver now checks the Logical Switch Port type and skips trunk management for external ports, leaving it to the appropriate out-of-band mechanism driver. For more information see bug 2167105.

  • The L3 agent now starts keepalived with -B (no BFD subsystem) if keepalived was built with BFD support. Since keepalived 2.3.2 every instance locks the BFD PID file, /run/bfd.pid by default, so HA routers failed to start if /run was read-only or if several routers were started at the same time.

  • The denormalised allocated flag in the ML2 allocation tables could diverge from networksegments, causing in-use segmentation IDs to be silently re-offered as free (LP#2167266). Deriving availability from networksegments removes this failure mode. See also LP#2168770.

  • Synchronizing the VLAN allocations no longer deletes allocated registers when it removes the registers of a physical network that is no longer configured. Deleting them discarded the only record that a segmentation ID was in use while the network segment referencing it still existed. Allocated registers are now kept and removed when their segment is released, which matches both the per-VLAN removal in the same routine and the behaviour of the tunnel type drivers. See bug: 2167266.

  • Tunnel segments with physical_network = NULL did not participate correctly in UNIQUE constraints on networksegments because SQL treats NULL values as distinct. See LP#2168770.

  • neutron-ovn-agent now honours the [OVS] ovsdb_timeout and [OVS] of_inactivity_probe options when it creates the OVSDB manager. It previously always used their default values.

  • An in-place change of a floating IP NAT external_mac now deletes the OVN MAC_Binding for that IP. ovn-controller only refreshes a MAC_Binding when an ARP is punted, and the stale entry prevents that ARP from being sent.

  • The OVN mechanism driver no longer uses the first port binding of a port to decide whether the port is an external port (lsp.type=external). When a port has multiple bindings, for example during live migration, the first binding could be the inactive one, resulting in the wrong VNIC type and capabilities being evaluated. The ACTIVE binding is now used.

  • Disassociating an OVN load balancer VIP floating IP restores the member floating IP external_mac from neutron:fip_external_mac, the floating IP port MAC stored when the NAT row was created. The previous code wrote the member VM port MAC, so OVN answered ARP for an address the network no longer uses.

  • Fixed a race condition in the ML2/OVN mechanism driver where a nova instance rebuild could time out waiting for the network-vif-plugged event. During a rebuild nova unplugs and quickly replugs the VIF on the same chassis, so the Logical_Switch_Port may never transition from DOWN to UP and LogicalSwitchPortUpdateUpEvent is not fired. The PortBindingChassisUpdateEvent now also matches a port being (re)bound to a chassis while the LSP stays up, emitting the required port status update (and therefore the vif-plugged event).

  • Fixed a KeyError when retrieving a port with a QoS policy that had no associated port binding register. The API now returns the port without a resource request and logs an error instead. For more information, see bug 2166602.

  • Project members can no longer delete the OVN metadata port of their network with DELETE /v2.0/ports/{id}. Deleting it broke metadata access for the instances of the network. Admin users can still delete it. For more information, see bug 1764408.

  • Adding a router interface on a subnet that is already attached to the router now fails with Router already has a port on subnet on routers supporting multiple external gateways (for example the OVN L3 plugin), instead of reporting that the subnet overlaps with itself. For more information, see bug 2170284.

Other Notes

  • Added extension ip_substring_filtering to the ML2/OVN mechanism driver.

  • Added extension network-segment-range to the ML2/OVN mechanism driver supported API extension list.