Current Series Release Notes

28.0.0.0rc1-159

New Features

  • The remove-duplicated-port-bindings script now supports a new --port CLI option. When specified, only the INACTIVE bindings for the specific port ID provided will be removed, leaving all other ports unaffected. This provides better control for operators who need to fix individual ports without risking unintended changes to other ports.

  • Add limiting and paging features for L3 agents.

    Listing ML2/OVN agents with these features is currently not supported, as only SQL-backed agents support them via the neutron-lib library. This gap is documented in the “Gaps from ML2/OVS” documentation.

Upgrade Notes

  • With the fix to bug 2147115 and extension aap-reject-multicast Allowed Address Pairs containing multicast addresses are no longer allowed. However such AAPs created earlier may remain in the DB (though they were not supported). Their presence could cause problems in updates to AAPs - because what’s already there is no longer accepted during an update. The API user can always recover from this situation by clearing AAPs and then re-setting the valid ones. During an upgrade it may make sense to clear multicast AAPs.

  • New default policy rules have been added for the address group CRUD and action operations (create_address_group, update_address_group, delete_address_group, add_addresses, remove_addresses). Each rule now requires the admin_or_project_member role by default, with scope_types=['project'].

  • The MTU configuration for OVN metadata port and OVN load balancer health monitor port tap interfaces now matches the network MTU. This change affects only newly created ports and the corresponding metadata datapaths. Existing metadata datapaths will not be updated when the network MTU is changed.

  • Now all service plugins, inheriting from ServicePluginBase class, and the ML2 plugins, will have the extension “filter-validation” enabled by default. That enforces the API filter validation in the queries, returning a HTTPBadRequest in case of using an invalid attribute. This extension can be enabled or disabled using the Neutron configuration variable [DEFAULT]filter_validation.

  • Default RBAC policies for the port actions listed above no longer include PROJECT_MANAGER. Deployments with customized policy files should review and update those rules if they rely on the previous behaviour.

  • The OVN L3 scheduler now uses HA_Chassis_Group and HA_Chassis tables instead of the deprecated Gateway_Chassis table for scheduling gateway Logical_Router_Port. This aligns with the preferred HA scheduling method in OVN since version 20.03.0. The redirect-chassis option in the Logical_Router_Port is no longer used. A new maintenance task automatically migrates any existing Gateway_Chassis references to the equivalent HA_Chassis_Group configuration.

  • The fip64 extension support has been removed from the floating IP pools code. This extension was only used by networking-midonet, which is no longer maintained. The is_v6_supported property and the fip64 extension check have been removed from FloatingIPPoolsDbMixin. Floating IP pools now only return IPv4 subnets.

Deprecation Notes

  • The tenant_id key in API and plugin code has been deprecated. Users should start using the project_id key in all objects and calls, as support for tenant_id will be removed in a future release. For more information see this Neutron blueprint

Security Issues

  • Fixed overly permissive default RBAC policies for several port actions that require network ownership. Those policies previously included PROJECT_MANAGER, which allowed any project manager to perform the action even when not owning the network (for example, on shared/RBAC networks). They now rely on NET_OWNER_MEMBER or ADMIN_OR_NET_OWNER_MEMBER only. Project managers who own the network remain authorized through the default Keystone role implication chain (manager implies member).

    Affected actions: create_port:device_owner, update_port:device_owner, create_port:mac_address, update_port:mac_address, create_port:fixed_ips, create_port:fixed_ips:ip_address, create_port:fixed_ips:subnet_id, update_port:fixed_ips, update_port:fixed_ips:ip_address, update_port:fixed_ips:subnet_id, create_port:port_security_enabled, update_port:port_security_enabled, create_port:allowed_address_pairs, create_port:allowed_address_pairs:mac_address, create_port:allowed_address_pairs:ip_address, update_port:allowed_address_pairs, update_port:allowed_address_pairs:mac_address, and update_port:allowed_address_pairs:ip_address.

  • Fixed a security issue where the tagging controller’s single-tag write endpoints (POST /v2.0/{resource}/{id}/tags and PUT /v2.0/{resource}/{id}/tags/{tag}) enforced policy action names using the plural collection key (e.g. create_networks:tags) instead of the singular member name (e.g. create_network:tags). Because the plural names did not match any registered policy rule, they fell through to oslo.policy’s default rule, allowing project readers to create and update tags on same-project resources. All tag-write endpoints now consistently use the singular policy action names that match the registered rules.

Bug Fixes

  • Multicast addresses in Allowed Address Pairs were never properly supported, but the API silently accepted them. With API extension aap-reject-multicast Neutron is going to reject these Allowed Address Pairs, so API and backend behavior becomes consistent. See bug: 2147115

  • The address group API was missing explicit policy rules for the create_address_group, update_address_group, delete_address_group, add_addresses, and remove_addresses actions. Without these rules, oslo.policy could not properly enforce access control on those operations, falling back to a default allow-all behaviour. Explicit DocumentedRuleDefault entries have been added for each action, aligned with the existing get_address_group rule style.

  • Fixed an issue where NetworkContext excluded dynamic segments from its network_segments list, causing mechanism drivers to fail when accessing dynamically allocated segments during hierarchical binding operations. The NetworkContext now includes dynamic segments by passing filter_dynamic=None to get_network_segments(), allowing the _expand_segment() method to successfully find dynamic segments in the in-memory cache. This fixes hierarchical binding cleanup scenarios where later drivers need to access segment information that was dynamically allocated by earlier drivers. [bug 2144501]

  • [bug 2152164] OVN metadata port and OVN load balancer health monitor port tap interfaces now have their MTU set to match the network MTU, ensuring consistency with VM interface MTU values. Previously, these interfaces had a default MTU that could differ from the network MTU, potentially causing packet fragmentation issues.

  • Fixed an issue where deleting a floating IP with dns_name and dns_domain set would fail with a 500 error when the associated Designate DNS records were managed. The Designate external DNS driver now passes edit_managed=True to the designateclient, allowing deletion of managed records. For more information see bug 2149807.

  • Fixed a memory leak in ExclusiveResourceProcessor where the _resource_timestamps class-level dictionary was never cleaned up when the primary processor exited. Over time, this caused stale entries to accumulate for every resource ID that was ever processed.

  • Fixed the delete_floatingips:tags policy rule name to use the correct singular form delete_floatingip:tags, consistent with all other tag-related policy rules.

  • The neutron-periodic-workers service now classifies plugin workers by worker_process_count before starting them. Workers with worker_process_count=0 are grouped in a single AllServicesNeutronWorker and executed as threads in one child process. Workers with worker_process_count>0 are started in separate child processes. MaintenanceWorker and AllServicesNeutronWorker instances are skipped by this service and must be started by their own executables.

  • Fixed ML2 mechanism driver notification order during port deletion to follow proper FILO (first-in, last-out) teardown semantics. Previously, mechanism drivers were notified of port deletion in the same forward order as port creation, which could cause the outermost binding level (closest to network fabric) to be torn down before the innermost level (closest to compute host) had a chance to clean up. This fix ensures that delete_port_precommit and delete_port_postcommit notify drivers in reverse order so that each binding level is properly cleaned up before the infrastructure beneath it is torn down. See bug 2153163.

  • ML2 now evaluates vlan_transparent and qinq mechanism driver support using tri-state results: True (supports), False (rejects), and None (abstains). Networks are accepted only when at least one mechanism driver reports support and no driver rejects support. See bug: 2131664.

  • Fixed a bug in the ML2/OVN OVSDB monitor event handlers where a single Neutron admin context was shared across all invocations of the PortBindingUpdateVirtualPortsEvent and LogicalSwitchPortUpdateLogicalRouterPortEvent event handlers. Reusing the same context (and its underlying SQLAlchemy session) could cause @transaction_guard failures, leading to silent event processing failures and port status update timeouts. Each event handler invocation now creates a fresh admin context.

  • The ML2/OVN mechanism driver now validates that virtual MAC addresses in allowed address pairs conform to the RFC 5798 VRRP ranges (00:00:5e:00:01:XX for IPv4 or 00:00:5e:00:02:XX for IPv6). Previously, non-conforming virtual MACs were silently accepted by the Neutron API but discarded by ovn-controller, leading to confusing behavior. For more information see bug 2144371.

  • The OVNL3RouterPlugin._post_fork_initialize method now returns early when the worker is not a Neutron API WorkerService instance. This prevents MechanismDriverOVNNotReady errors in the neutron-periodic-workers and other non-API processes, where the OVN IDL connections are not initialized.

  • The OVNL3RouterPlugin now registers OVN OVSDB events (LogicalRouterPortEvent and RouterHAChassisGroupEvent) only in Neutron API workers (WorkerService instances). Previously these events were registered by every worker type that called _post_fork_initialize, which could lead to unexpected event processing in maintenance or other non-API workers.

Other Notes

  • The Neutron API no longer allows creating VLAN network if ovn-bgp service plugin is enabled. The ovn-bgp service plugin requires Spine And Leaf topology which makes it incompatible with the VLAN network segregation.

  • Added documentation for Neutron notification events and their payloads. The admin guide explains how notifications are configured and when they are emitted. The reference guide lists CRUD event patterns, example payloads for core resources, and special events such as router interface changes, resource tags, agent scheduling, metering, and usage audit.

  • ML2/OVN now reads the Logical_Router_Port HA_Chassis_Group instead of the legacy Gateway_Chassis when syncing the external ports HA_Chassis_Group of the connected networks. The HA_Chassis_Group change event on the router is now monitored to keep both the router and the network chassis groups in sync.

  • When the ML2/OVN mechanism driver is used, the OVN L3 router plugin no longer inherits L3RpcNotifierMixin. This removes four @registry.receives callbacks (PORT AFTER_DELETE, PORT AFTER_UPDATE, SUBNET AFTER_UPDATE, SUBNETPOOL_ADDRESS_SCOPE AFTER_UPDATE) that were previously registered at plugin instantiation time but served no purpose in the OVN backend. These callbacks executed unnecessary DB queries on every matching event only to reach the no-op RPCNotifierHandler. A new L3NotifierMixin base class now provides the notifier property and notification helpers without registering any event callbacks, allowing backends that do not need RPC workers to avoid this overhead.

  • ML2/OVN virtual ports no longer store the host information in the port binding host field. Instead, the host where the virtual port is active is now reported in the VIF details under the parent_hostname key.

  • All service plugins should inherit from neutron_lib.services.base.ServicePluginBase. A warning message will be printed if the plugin doesn’t match this condition with a recommendation to file a Launchpad bug.

  • Neutron workers now log DEBUG messages when their lifecycle methods (start, wait, stop, and reset) are called and finished. The log entries include the worker class name and worker description, which helps troubleshoot neutron-periodic-workers, RPC workers, and other child processes.