2023.1 Series Release Notes¶
When using ML2/OVN, during an upgrade procedure, the OVS system-id stored value can be changed. The ovn-controller service will create the “Chassis” and “Chassis_Private” registers based on this OVS system-id. If the ovn-controller process is not gracefully stopped, that could lead to the existence of duplicated “Chassis” and “Chassis_Private” registers in the OVN Southbound database.
[bug 2022914] Neutron-API supports using relays as the southbound connection in a ML2/OVN setup. Before the maintenance worker of the API required a leader_only connection, which was removed.
Fixed the scenario where the DHCP agent is deployed in conjunction with the OVN metadata agent in order to serve metadata for baremetal nodes. In this scenario, the DHCP agent would not set the route needed for the OVN metadata agent service resulting in baremetal nodes not being able to query the metadata service. For more information see bug 1982569.
For OVN versions v22.09.0 and above, the
mcast_flood_reportsoption is now set to
falseon all ports except “localnet” types. In the past, this option was set to
trueas a workaround for a bug in core OVN multicast implementation.
Now the ML2/OVN trunk driver prevents a trunk creation if the parent port is already bound. In the same way, if a parent port being used in a trunk is bound, the trunk cannot be deleted.
During the port bulk creation, if an IPAM allocation fails (for example, if the IP address is outside of the subnet CIDR), the other IPAM allocations already created are deleted before raising the exception. Fixes bug 2039550.
A new OVN maintenance method
remove_duplicated_chassis_registersis added. This method will periodically check the OVN Southbound “Chassis” and “Chassis_Private” tables looking for duplicated registers. The older ones (based on the “Chassis_Private.nb_cfg_timestamp” value) will be removed when more than one register has the same hostname, that should be unique.
The external_mac entry in the NAT table is used to distribute/centralize the traffic to the FIPs. When there is an external_mac set the traffic is distributed (DVR). When it is empty it is centralized through the gateway port (no DVR). Upon port status transition to down, the external_mac was removed regardless of DVR being enabled or not, leading to centralize the FIP traffic for DVR – though it was for down ports that won’t accept traffic anyway.
Adds a maintenance task that runs once a day and is responsible for cleaning up Hash Ring nodes that haven’t been updated in 5 days or more. See LP #2033281 for more information.
Added the missing extension
uplink-status-propagationto the ML2/OVN mechanism driver. This extension is used by the ML2/SR-IOV mechanism driver, that could be loaded with ML2/OVN. Now it is possible to create ports with the “uplink-status-propagation” flag defined.
A ML2/OVN virtual port cannot be bound to a virtual machine. If a port IP address is assigned as an allowed address pair into another port, the first one is considered a virtual port. If the second port (non-virtual) is bound to ML2/OVN, the virtual port cannot be bound to a virtual machine; a virtual port is created only to reserve a set of IP addresses to be used by other ports. The OVN mechanism driver prevents that a virtual port has a device ID; a device ID is provided when the port is being bound.
The high availability of metadata service on isolated networks is limited or non-existent. IPv4 metadata is redundant when the DHCP agent managing it is redundant, but recovery is tied to the renewal of the DHCP lease, making most recoveries very slow. IPv6 metadata is not redundant at all as the IPv6 metadata address can only be configured in a single place at a time as it is link-local. Multiple agents trying to configure it will generate an IPv6 duplicate address detection failure.
Administrators may observe the IPv6 metadata address in “dadfailed” state in the DHCP namespace for this reason, which is only an indication it is not highly available. Until a redesign is made to the isolated metadata service there is not a better deployment option. See bug 1953165 for information.
The redirect-type=bridged option is only used if all the tenant networks connected to the router are of type VLAN or FLAT. In this case their traffic will be distributed. However, if there is a mix of VLAN/FLAT and geneve networks connected to the same router, the redirect-type option is not set, and therefore the traffic for the VLAN/FLAT networks will also be centralized but not tunneled.
1986003 Fixed an issue with concurrent requests to activate the same port binding where one of the requests returned a 500 Internal Server Error. With the fix one request will return successfully and the other will return a 409 Conflict (Binding already active). This fixes errors in nova live-migrations where those concurrent requests might be sent. Nova handles the 409/Conflict response gracefully.
Fix an issue in the OVN driver where network metadata could become unavailable if the metadata port was ever deleted, even if accidental. To re-create the port, a user can now disable, then enable, DHCP for one of the subnets associated with the network using the Neutron API. This will try and create the port, similar to what happens in the DHCP agent for ML2/OVS. For more information, see bug 2015377.
[bug 2003455] As part of a previous commit (https://review.opendev.org/c/openstack/neutron/+/875644) the redirect-type=bridged option was set in all the router gateway ports (cr-lrp ovn ports). However this was breaking the N/S traffic for geneve tenant networks connected to the provider networks through those routers with the redirect-type option enabled. To fix this we ensure that the redirect-type option is only set if all the networks connected to the router are of VLAN or FLAT type, otherwise we fall back to the default option. This also means that if there is a mix of VLAN and geneve tenant networks connected to the same router, the VLAN traffic will be centralized (but not tunneled). If the traffic for the VLAN/FLAT needs to be distributed, then it should use a different router.
Address scope is now added to all OVN LSP port registers in the northbound. Northd then writes the address scope from the northbound to the southbound so it can be used there by the ovn-bgp-agent.
Manila owned ports can now have multiple port bindings associated in order to support nondisruptive Manila share server migration across physical networks.
Extend routed provider networks to allow provisioning more than one segment per physical network.
Introducing clean_devices, a new DHCP driver’s API that can be called to clean stale devices.
Added a new agent: the OVN Agent. This new agent will run on a compute or a controller node using OVN as network backend, similar to other ML2 mechanism drivers as ML2/OVS or ML2/SRIOV. This new agent will perform those actions that the ovn-controller service cannot execute. The agent functionality will be plugable and added via configuration knob.
Added a new OVN Neutron Agent extension: QoS for hardware offloaded ports. This extension will enforce the minimum and maximum bandwidth egress QoS rules for ports with hardware offload (DevLink ports). This extension uses the “ip-link” commands to set the “ceil” and “rate” parameters on the corresponding virtual functions.
ML2/OVS and ML2/OVN now support modelling tunnelled networks in the Placement API. The “tunnelled_network_rp_name” configuration option defines the resource provider name used to represent all tunnelled networks in a compute node (by default “rp_tunnelled”). If this string is present in the “resource_provider_bandwidths” dictionary, the corresponding mechanism driver will create a resource provider for the overlay traffic.
Neutron now supports API policies with the new default roles
adminis working in the same way as with old policies.
Until the OVN bug (https://bugzilla.redhat.com/show_bug.cgi?id=2162756) is fixed, setting the “reside-on-redirect-chassis” to true for the logical router port associated to vlan provider network is needed. This workaround makes the traffic centrallized, but not tunneled, through the node with the gateway port, thus avoiding MTU issues.
The default value for the
metadata_workersconfiguration option has changed to 0 for the ML2/OVN driver. Since [OVN] Allow to execute “MetadataProxyHandler” in a local thread, the OVN metadata proxy handler can be spawned in the same process of the OVN metadata agent, in a local thread. That reduces the number of OVN SB database connections to one.
The deprecated config option
New default API policies are not enabled by default. A cloud operator can enable them by setting
truein the Neutron config file. It is also possible to switch the
oslo_policy/enforce_scopeconfig option to
truebut currently Neutron does not support any system scope APIs. All Neutron API policies are currently project scoped so setting
Forbiddenresponses to any API calls made with the system scope token.
allow_stateless_action_supportedis deprecated to removal and will be removed in
2023.2 (Bobcat)release. This option will not be needed anymore as Neutron will not be supported to be run with OVN < 21.06.
1996677 When the fixed_ips of metadata port is modified, the ip address of tap device in metadata agent is modified.
[bug 2003455] It is added an extra checking to ensure the “reside-on-redirect-chassis” is set to true for the logical router port associated to vlan provider network despite having the “ovn_distributed_floating_ip” enabled or not. This is needed as there is an OVN bug (https://bugzilla.redhat.com/show_bug.cgi?id=2162756) making it not work as expected. Until that is fixed, we need these workaround that makes the traffic centrallized, but not tunneled, through the node with the gateway port, thus avoiding MTU issues.
Normalise OVN agent heartbeat timestamp format to match other agent types. This fixes parsing of
GET /v2.0/agentsfor some clients, such as gophercloud.
Neutron can record full connection using log-related feature introduced in OVN 21.12. For more info see bug LP#<https://bugs.launchpad.net/neutron/+bug/2003706>
Since OVN 20.06, the “Chassis” register configuration is stored in the “other_config” field and replicated into “external_ids”. This replication is stopped in OVN 22.09. The ML2/OVN plugin tries to retrieve the “Chassis” configuration from the “other_config” field first; if this field does not exist (in OVN versions before 20.06), the plugin will use “external_ids” field instead. Neutron will be compatible with the different OVN versions (with and without “other_config” field).
OVN mechanism driver has now got config option
allow_stateless_action_supportedwhich allows manually disable
stateful-security-groupAPI extension in case when OVN older than 21.06 is used because support for
allow-statefulaction in OVN’s ACL was added in OVN 21.06. By default this option is set to
stateful-security-groupAPI extension is enabled. If this option is set to
Trueand OVN < 21.06 is used, Neutron will fallback to the statefull ACLs even if SG is set to be stateless in Neutron database.
ProcessManagerclass will now, by default, add an environment variable when starting a new process. This default tag is named “PROCESS_TAG” and will contain a unique identifier for this specific process. It could be used, for example, by TripleO to univocally tag any new container spawned and find it using the same tag.