Wallaby Series Release Notes

18.0.0-24

Known Issues

  • When using the minimim-bandwidth QoS feature due to bug https://launchpad.net/bugs/1921150 physical NIC resource providers were for some time created with the wrong parent (i.e. the hypervisor RP). This is now partially fixed and new resource providers are created now with the expected parent (i.e. the agent RP). However Placement does not allow re-parenting an already existing resource provider, therefore the following Placement DB update may be needed after the fix for bug 1921150 is applied: neutron/tools/bug-1921150-re-parent-device-rps.sql Until all resource providers have the proper parent, neutron-server will retry the re-parenting update, which will be rejected every time, therefore expect polluted logs and some wasted load on Placement. However please note that the bandwidth-aware scheduling is supposed to work even with the wrongly parented resource providers.

18.0.0

New Features

  • Security group rule has now new, read only attribute normalized_cidr which contains network address from the CIDR provided in the remote_ip_prefix attribute. This new attribute shows actual CIDR used by backend firewall drivers.

  • Support for network logging based on security groups added to OVN backend. For more information see bug 1914757.

  • Now it is possible to define a gateway IP when creating a subnet using a subnet pool. If the gateway IP can be allocated in one of the subnet pool available subnets, this subnet is created; otherwise a Conflict exception is raised.

  • A new subnet of type network:routed has been added. If such a subnet is used, the IPs of that subnet will be advertized with BGP over a provider network, which itself can use segments. This basically achieves a BGP-to-the-rack feature, where the L2 connectivity can be confined to a rack only, and all external routing is done by the switches, using BGP. In this mode, it is still possible to use VXLAN connectivity between the compute nodes, and only floating IPs and router gateways are using BGP routing.

  • Added support for the vlan-transparent in the OVN mechanism driver.

  • Introduce the attribute port_device_profile to ports that specifies the device profile needed per port. This parameter is a string. This parameter is passed to Nova and Nova retrieves the requested profile from Cyborg: Device profiles.

    Operators can turn on this feature via the configuration option:

    [ml2]
    extension_drivers = port_device_profile
    
  • Neutron now experimentally supports new API policies with the system scope and the default roles (member, reader, admin).

  • Added support in SR-IOV agent for accelerator-direct VNIC type. This type represents a port that supports any kind of hardware acceleration and is provided by Cyborg (https://wiki.openstack.org/wiki/Cyborg). RFE: 1909100. accelerator-direct-physical is still not supported.

  • A new API resource address group and its CRUD operations are introduced to represent a group of IPv4 and IPv6 address blocks. A new option --remote-address-group is added to the security group rule create command to allow network connectivity with a group of address blocks. And the backend support is added to the openvswitch firewall. When IP addresses are updated in the address groups, changes will also be reflected in the firewall rules of the associated security group rules. For more information, see RFE: 1592028

  • Add support for deleting ML2/OVN agents. Previously, deleting an agent would return a Bad Request error. In addition to deleting the agent, this change also drastically improves the scalability of the ML2/OVN agent handling code.

  • Update of an already bound port with a QoS minimum_bandwidth rule with a new QoS policy with a minimum_bandwidth rule now changes the allocations in placement as well.

    Note

    Updating the minimum_bandwidth rule of a QoS policy that is attached to a port which is bound to a VM is still not possible.

  • A new vnic type vdpa has been added to allow requesting port that utilize a vHost-vDPA offload. The ML2/OVS and ML2/OVN mech drivers now have support for the vHost-vDPA vnic type. vHost-vDPA is similar to vHost-user or kernel vhost offload but utilizes the newly added vDPA bus introduced in the Linux 5.7 kernel. vDPA interface can be implemented in software or hardware, when implemented in hardware they provide equivalent performance to SR-IOV or hardware offloaded OVS while providing two main advantages over both SR-IOV and hardware offloaded OVS. Unlike the alternatives, vHost-vDPA enables live migration of instance transparently and provides a standard virtio-net interface to the guest avoiding the need to install vendor specific drivers in the guest.

  • OVN driver now supports VXLAN type for networks. This requires OVN version to be 20.09 or newer.

Known Issues

  • Even with the “igmp_snooping_enable” configuration option stating that traffic would not be flooded to unregistered VMs when this option was enabled, the ML2/OVN driver didn’t follow that behavior. This has now been fixed and ML2/OVN will no longer flood traffic to unregistered VMs when this configuration option is set to True.

  • Support for new policies and system scope context is experimentatal in Neutron. When config option enforce_new_defaults is enabled in Neutron, new default rules will be enforced and things may not work properly in some cases.

Upgrade Notes

  • Address group now has standard attributes. In the alembic migration, the original description column of address_groups is dropped after data migrated to the standardattributes table. The description field is also removed from the address group object and DB model. This change requires a restart of neutron-server service after the DB migration otherwise users will get server errors when making calls to address group APIs.

  • The default value of [oslo_policy] policy_file config option has been changed from policy.json to policy.yaml. Operators who are utilizing customized or previously generated static policy JSON files (which are not needed by default), should generate new policy files or convert them in YAML format. Use the oslopolicy-convert-json-to-yaml tool to convert a JSON to YAML formatted policy file in backward compatible way.

Deprecation Notes

  • Use of JSON policy files was deprecated by the oslo.policy library during the Victoria development cycle. As a result, this deprecation is being noted in the Wallaby cycle with an anticipated future removal of support by oslo.policy. As such operators will need to convert to YAML policy files. Please see the upgrade notes for details on migration of any custom policy files.

  • Deprecate keepalived_use_no_track config option, as keepalived version check is a safe source to decide if no_track can be used in keepalived configuration file.

  • Removed XenAPI support in Neutron. This driver is no longer supported in Nova and Neutron. The configuration options have been marked as “deprecated for removal” and will be removed in X release.

  • Old API policies are deprecated now. They will be removed in future.

Bug Fixes

  • Stop sending agent heartbeat from ovs agent when it detects OVS is dead. This helps to alarm cloud operators that there is something wrong on the given node.

  • Fixed a MAC learning issue when OVS offload is enabled. The OVS firewall reduces the usage of normal actions to reduce CPU utilization. This causes insertion of a flood rule because there is no MAC learning on ingress traffic. While this is okay for the non-offload case, when using OVS offload the flood rule is not being offloaded. This fixes the MAC learning in the offload case, so we avoid the flood rule. For more information, see bug 1897637.

  • Fixes a configuration problem in the OVN driver that prevented external IGMP queries from reaching the Virtual Machines. See bug 1918108 for details.

Other Notes

  • Added a new config option enable_traditional_dhcp for neutron server, if it is set to False, neutron server will disable DHCP provisioning block, DHCP scheduler API extension, network scheduling mechanism and DHCP RPC/notification. This option can be used with the dhcp extension of the OVS agent to enable distributed DHCP, or for a deployment which needs to disable the DHCP agent related functions permanently.

  • To improve performance of the DHCP agent, it will no longer configure the DHCP server for every port type created in Neutron. For example, for floating IP or router HA interfaces there is no need since a client will not make a DHCP request for them

  • The OVN Metadata Agent now creates the network namespaces including the Neutron network UUID in its name. Previously, the OVN datapath UUID was used and it was not obvious for operators and during debugging to figure out which namespace corresponded to what Neutron network.

  • As defined in Migrate from oslo.rootwrap to oslo.privsep, all OpenStack proyects should migrate from oslo.rootwrap to oslo.privsep because “oslo.privsep offers a superior security model, faster and more secure”. This migration will end with the deprecation and removal of oslo.rootwrap from Neutron. To ensure the quality of the Neutron code, this migration will be done sequentially in several patches, checking none of them breaks the current functionality. In order to easily migrate to execute all external commands inside a privsep context, a new input variable “privsep_exec”, that defaults to “False”, is added to neutron.agent.linux.utils.execute. That will divert the code to a privsep decorated executor. Once the migration finishes, this new input parameter will be removed.

  • When new default values for API policies are enabled, some API requests may not be available for project admin users anymore as they are possible only for system scope users. Please note that system scope tokens don’t have project_id included so for example creation of the provider network, with specified physical network details will now require from system scope admin user to explicitly set project_id.