2024.2 Series Release Notes

25.0.0

New Features

  • Neutron API RBAC policies now support by default the project MANAGER role. Please refer to the community goal for more information.

  • New ML2 plugin extension port_trusted is now available. This extension implements the port_trusted_vif API extension which adds to the port resource a new boolean field called trusted. This field should be used by admin users to set the port as trusted what was previously possible only through the port’s binding:profile dictionary. Value of the trusted field is still visible in the port’s binding:profile dictionary so that for example Nova still has it where it is expected to be.

  • The OVN ML2 mechanism driver for static routes will now include the key neutron:is_static_route in the external_ids register for external gateway router ports. This is required for the OVN DB sync tool to distinguish the Neutron created Static Routes from those added externally in the OVN database. Previously created static route rules will be updated only once during the maintenance task to include the neutron:is_static_route key in the external_ids register. In case all static route entries are already configured using this key, no maintenance action will be performed.

  • A new module, neutron.wsgi, has been added as a place to gather WSGI application objects. This is intended to ease deployment by providing a consistent location for these objects. For example, if using uWSGI then instead of:

    [uwsgi]
    wsgi-file = /bin/neutron-api
    

    You can now use:

    [uwsgi]
    module = neutron.wsgi.api:application
    

    This also simplifies deployment with other WSGI servers that expect module paths such as gunicorn.

  • A new sample OVN user defined router flavor driver has been added that enables the creation of router interfaces with no associated underlying Logical Switch Ports. In this scenario, Neutron only acts as the IP address manager for the router interfaces. This enables user defined router flavors to have total control of the traffic traversing the router interfaces while bypassing the OVN processing.

  • Added a new configuration option called broadcast_arps_to_all_routers to the [ovn] config section. This option is responsible for configuring the external networks with the broadcast-arps-to-all-routers config option available in OVN 23.06 and newer. By enabling this option (default) OVN will flood ARP requests to all attached ports on a network. If disabled, ARP requests are only sent to routers on that network if the target MAC address matches. ARP requests that do not match a router will only be forwarded to non-router ports.

  • Remote address group support was added to the iptables-based firewall drivers (IptablesFirewallDriver and OVSHybridIptablesFirewallDriver), Previously it was only available in the OVSFirewallDriver. For more information, see bug 2058138.

  • OVN routers can be attached to tunnelled external gateway networks. The Logical Router is pinned to a gateway chassis, instead of the gateway Logical Router Port. The mechanism driver monitors the status of the gateway chassis to re-schedule the Logical Router in case of failure, providing high availability.

  • Added a new process called neutron-ovn-maintenance-worker. This process is spawned when using the ML2/OVN mechanism driver and Neutron API WSGI module. It executes the maintenance task needed by the ML2/OVN mechanism driver to sync the Neutron and OVN databases.

  • Added a new process called neutron-periodic-workers. This process is spawned when using the Neutron API WSGI module with any mechanism driver. It executes the ML2 plugin periodic workers that are collected by an instance of the class AllServicesNeutronWorker and executed as threads on a single worker.

  • A new ML2 OVN driver configuration option ovn_router_indirect_snat was added. When set to True, all external gateways will enable SNAT for all nested networks that are indirectly connected to gateways (through other routers). This option mimics the router service plugin behavior used with ML2 Open vSwitch and some other backends.

  • Added a new shim extension tag-creation. This extension informs about a new API definition in the tag plugin that allows to send POST requests. Now it is possible to create new tags, passing the value of the tags as an argument of the call. That resolves formatting issues when using URI reserved characters.

Deprecation Notes

  • Setting trusted key directly in the port’s binding:profile is deprecated and will be forbidden in future releases. Dedicated port’s attribute trusted, added by the API extension port_trusted_vif should be used instead.

  • Removed the maintenance method remove_duplicated_chassis_registers. This method is no longer needed since OVN 21.03.0. For more information, see the bug 2073613.

  • Removed the support for Windows OS.

Security Issues

  • A ML2/SR-IOV port with status=DOWN will always set the VF link state to “disable”, regardless of the propagate_uplink_status port field value. The port disabling, to stop any transmission, has precedence over the link state “auto” value.

Bug Fixes

  • Cleaned non-harmful stack trace errors from DNS integration plugin. This prevents the logs from filling with stack traces where error log messages would have been sufficient.

  • Fixes an issue when associating floating IPs to OVN load balancers. See LP#2068644 for more details.

Other Notes

  • In some of previous versions of Neutron, it was not possible to create or delete a trunk port if it was bound to a parent port when using ML2/OVN driver. This restriction has been removed in this release. ML2/OVS driver still has this restriction due to backend limitations.

  • Neutron uses a new algorithm to compare the differences between security group rules in Neutron and ACLs in OVN. Before comparison, the data is sorted according to the security group rule ID, then the two ordered arrays are compared. This increases efficiency when larger sets of rules need to be synchronized.

  • Enhance error handling in the Neutron metadata service for cases when the Nova metadata service is unavailable, ensuring correct HTTP status codes are returned.