Current Series Release Notes

Current Series Release Notes

14.0.0.0b3-40

Prelude

Support alias end points for rules in QoS API.

New Features

  • The qos-rules-alias API extension was implemented to enable users to perform GET, PUT and DELETE operations on QoS rules as though they are first level resources. In other words, the user doesn’t have to specify the QoS policy ID.

Upgrade Notes

  • The external_network_bridge config option has been removed. Existing users of this option will now have their router’s gateway interface created in the integration bridge and it will be wired by the L2 agent.
  • The Neutron API now enforces that ports are a valid option for security group rules based on the protocol given, instead of relying on the backend firewall driver to do this enforcement, typically silently ignoring the port option in the rule. The valid set of whitelisted protocols that support ports are TCP, UDP, UDPLITE, SCTP and DCCP. Ports used with other protocols will now generate an HTTP 400 error. For more information, see bug 1818385.

14.0.0.0b3

Prelude

Added support for network segment range management. This introduces the ability for administrators to control the segment ranges globally or on a per-tenant basis via the Neutron API.

Existing subnets that were created outside of a subnet pool can know be moved, or “onboarded” into an existing subnet pool. This provides a way for subnets to be brought under the management of a subnet pool and begin participating in an address scope. By enabling onboarding, existing subnets can be used with features that build on subnet pools and address scopes. Subnet onboarding is subject to all the same restrictions as and guarantees currently enforced by subnet pools and address scopes.

New Features

  • Before Stein, network segment ranges were configured as an entry in ML2 config file /etc/neutron/plugins/ml2/ml2_conf.ini that was statically defined for tenant network allocation and therefore had to be managed as part of the host deployment and management. The new network-segment-range API extension has been introduced, which exposes the network segment ranges to be administered via API. This allows users with admin privileges to be able to dynamically manage the shared and/or tenant specific network segment ranges. Standard attributes with tagging support are introduced to the new resource. The feature is controlled by the newly-added service plugin network_segment_range. A set of default network segment ranges will be created out of the ranges that are defined in the host ML2 config file /etc/neutron/plugins/ml2/ml2_conf.ini, such as network_vlan_ranges, vni_ranges for ml2_type_vxlan, tunnel_id_ranges for ml2_type_gre and vni_ranges for ml2_type_geneve.
  • Security groups are now supported via the network RBAC mechanism. Please refer to the admin guide for further details.
  • Neutron child processes now set their process titles to match their roles (‘api worker’, ‘rpc worker’, ‘periodic worker’, ‘services worker’, or any other defined by workers from out-of-tree plugins.) This behavior can be disabled by setting the setproctitle config option in the [default] section in neutron.conf to off. The original process string is also appended to the end, to help with scripting that is looking for the old strings. There is also an option called brief, which results in much shorter and easier to read process names. The default setting for this option is on, for a combination of backwards compatibility and identifying different processes easily. The recommended setting is brief, once the deployer has verified that none of their tooling depends on the older strings.
  • Existing subnets can now be moved into a subnet pool, and by extension can be moved into address scopes they were not initially participating in.

Upgrade Notes

  • The change to the process title happens by default with the new setproctitle config option. The old string is still part of the new process title, but any scripts looking for exact string matches of the old string may need to be modified.

14.0.0.0b2

New Features

  • L3 agent supports QoS bandwidth limit functionality for port forwarding floating IPs now. If floating IP has binding QoS policy (with bandwidth limit rules), the traffic bandwidth will be limited.
  • Add config option rpc_response_max_timeout to configure the maximum time waiting for an RPC response.

Upgrade Notes

  • The number of api and rpc workers may change on upgrade. It is strongly recommended that all deployers set these values in their neutron configurations, rather than using the defaults.
  • During the dependency resolution procedure, the code that loads service plugins was refactored to not raise an exception if one plugin is configured multiple times, with the last one taking effect. This is a change from the previous behavior.

Bug Fixes

  • Fixes an issue causing IP allocation on port update to fail when the initial IP allocation was deferred due to lack of binding info. If both the port mac_address and binding info (binding_host_id) were updated in the same request, the fixed_ips field was added to the request internally. The code to complete the deferred allocation failed to execute in that case. (For more information see bug 1811905.)
  • Neutron API workers default to the number of CPU cores. This can lead to high cpu/low memory boxes getting into trouble. The defaults have been tweaked to attempt to put an upper bound on the default of either the number of cores, or half of system memory, whichever is lower. In addition, the default number of RPC workers has been changed from a value of 1, to a value of half the number of API workers.

Other Notes

  • If an instance port is under a dvr router, and the port already has binding port forwarding(s). Neutron will no longer allow binding a floating IP to that port again, because dvr floating IP traffic rules will break the existing port forwarding functionality.
  • Neutron server now rejects (as NotImplementedError) updates of minimum_bandwidth QoS rules if the rule is already in effect on bound ports. Implementing updates will require updates to Placement allocations and possibly migrating servers where the new minimum_bandwidth can be satisifed.
  • Neutron now supports having service plugins require other plugin(s) as dependencies. For example, the port_forwarding service plugin requires the router service plugin to achieve full functionality. A new list, required_service_plugins, was added to each service plugin so the required dependencies of each service plugin can be initialized. If one service plugin requires another, but the requirement is not set in the config file, neutron will now initialize it to the plugin directory.

14.0.0.0b1

Prelude

Add new tool neutron-status upgrade check.

New Features

  • New framework for neutron-status upgrade check command is added. This framework allows adding various checks which can be run before a Neutron upgrade to ensure if the upgrade can be performed safely. Stadium and 3rd party projects can register their own checks to this new neutron-status CLI tool using entrypoints in neutron.status.upgrade.checks namespace.
  • Add support for listing floating ip pools (subnets) in L3 plugin. A new API resource floatingip-pools is introduced. This API endpoint can return a list of floating ip pools which are essentially mappings between network UUIDs and subnet CIDRs. Users can use this API to find out the pool to create the floating IPs.
  • Introduce the attribute propagate_uplink_status to ports. Right now, the SRIOV mechanism driver leverages this attribute to decide if the VF link should follow the state of the PF. For example, if the PF is down, the VF link state is automatically set to down as well. Operators can turn on this feature via the configuration option:

    [ml2]
    extension_drivers = uplink_status_propagation
    

    The API extension uplink_status_propagation is introduced to indicate if this feature is turned on.

  • New configuration options for neutron-ovs-agent under section [ovs]: resource_provider_bandwidths and resource_provider_inventory_defaults. The former controls the total (available bandwidth) field of the physical network interface resource provider inventories. It defaults to not creating resource providers in Placement. The latter can be used to tune the other fields (allocation_ratio, min_unit, max_unit, reserved, step_size) of resource provider inventories.
  • New configuration options for neutron-sriov-agent under section [sriov_nic]: resource_provider_bandwidths and resource_provider_inventory_defaults. The former controls the total (available bandwidth) field of the physical network interface resource provider inventories. It defaults to not creating resource providers in Placement. The latter can be used to tune the other fields (allocation_ratio, min_unit, max_unit, reserved, step_size) of resource provider inventories.
  • A new config option resync_throttle has been added for Neutron DHCP agent. This new option allows to throttle the number of resync state events between the local DHCP state and Neutron to only once per resync_throttle seconds. Default value for this new option is set to 1 and it should be configured per a user’s specific scenario, i.e. how responsive the user would like his/her system to be for those DHCP resync state events. The option is introduced together with the event driven periodic task for DHCP agents. This enhances the agent with a faster reaction on the resync request but ensuring a minimum interval taken between them to avoid too frequent resyncing. For more information see bug 1780370.
  • A new attribute qos_policy_id is added to the L3 router gateway.
    • It enables users to associate QoS policies to L3 router gateways to control the rate of transmission of the associated SNAT traffic.
    • At the moment, only bandwidth limit rules are supported in the QoS polices.
    • To enable this feature, the qos service plugin has to be configured in the Neutron server and the gateway_ip_qos extension has to be configured in the L3 agents. Please refer to the QoS section of the OpenStack Networking Guide for more specific details.
  • Add get_standard_device_mappings to SriovNicSwitchMechanismDriver and OpenvswitchMechanismDriver so they can return the interface or bridge mappings in a standard way. The common format is a dict like: {‘physnet_name’: [‘device_or_bridge_1’, ‘device_or_bridge_2’]}.

Upgrade Notes

  • Operator can now use new CLI tool neutron-status upgrade check to check if Neutron deployment can be safely upgraded from N-1 to N release.
  • Adds Floating IP port forwarding table column protocol to the uniq constraints. In one expand script, we drop the original uniq constraints first, then create the new uniq constraints with column protocol.
  • The deprecated ovsdb_interface configuration option has been removed, the default native driver is now always used. In addition, the deprecated ovs_vsctl_timeout option, which was renamed to ovsdb_timeout in Queens, has also been removed.

Deprecation Notes

  • The signature of notifications for resource agent for events after_create and after_update was extended. A new keyword argument was added: status. This is to make the same status information available to notification consumers as it was available already where the notification is sent in class AgentDbMixin. Valid status values are defined in neutron_lib.agent.constants. Consuming notifications by the old signature is deprecated. Unless processing arguments as **kwargs, out-of-tree notification consumers need to adapt.
  • Function get_binding_levels from neutron.plugins.ml2.db module is deprecated and will be removed in the future. New function get_binding_levels_objs should be used instead. This new function returns PortBindingLevel OVO objects.

Bug Fixes

  • Floating IP port forwardings with different protocols could not have the same internal or external port number to the same VM port. After this fix we will allow creating port forwardings with same internal or external port number in different protocols.
  • Fixes bug 1501206. This ensures that DHCP agent instances running dnsmasq as a DNS server can no longer be exploited as DNS amplifiers when the tenant network is using publicly routed IP addresses by adding an option that will allow them to only serve DNS requests from local networks.
  • Add resource_type into log object query to distinguish between security group and firewall group log objects. For more information see bug 1787119.

Other Notes

  • Support fetching specific db column in OVO. A new method get_values is added to neutron object classes. This method can be leveraged to fetch specific field of the object.
  • Add new configuration group ovs_driver and new configuration option under it vnic_type_blacklist, to make the previously hardcoded supported_vnic_types parameter of the OpenvswitchMechanismDriver configurable. The vnic_types listed in the blacklist will be removed from the supported_vnic_types list.
  • Add new configuration group sriov_driver and new configuration option under it vnic_type_blacklist, to make the previously hardcoded supported_vnic_types parameter of the SriovNicSwitchMechanismDriver configurable. The vnic_types listed in the blacklist will be removed from the supported_vnic_types list.
  • The metering agent iptables driver can now load its interface driver by using a stevedore alias in the metering_agent.ini file. For example, interface_driver = openvswitch instead of interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
  • Use publish for AGENT's AFTER_CREATE and AFTER_UPDATE events with DBEventPayload instead of the deprecated notify callback.
Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.