diff --git a/doc/source/admin/ovn/availability_zones.rst b/doc/source/admin/ovn/availability_zones.rst new file mode 100644 index 00000000000..a12599c3b7c --- /dev/null +++ b/doc/source/admin/ovn/availability_zones.rst @@ -0,0 +1,373 @@ +.. _ovn_availability_zones: + +================================ +Availability Zones guide for OVN +================================ + +The purpose of this page is to describe how the availability zones works +with OVN. Prior to reading this document, it is recommended to first +read :ref:`ML2/OVS driver Availability Zones guide`. + +There are two types of availability zones available in Neutron: Router +and Network. For ML2/OVS, this is related to the scheduling of the L3 +agent and DHCP agent respectively. For ML2/OVN, it's about the scheduling +of logical router ports and "external" ports respectively. + +More details about each type of availability zones can be found later +in this document but first let's go over the common parts between them: + +How to configure it +------------------- + +Different from the ML2/OVS driver for Neutron the availability zones for +the OVN driver is not configured via a configuration file. Since ML2/OVN +does not rely on an external agent such as the L3 agent, certain nodes +(e.g gateway/networker node) won't have any Neutron configuration file +present. For this reason, OVN uses the local OVSDB for configuring the +availability zones that instance of ``ovn-controller`` running on that +hypervisor belongs to. + +The configuration is done via the ``ovn-cms-options`` entry in +*external_ids* column of the local *Open_vSwitch* table: + +.. code-block:: bash + + $ ovs-vsctl set Open_vSwitch . external-ids:ovn-cms-options="enable-chassis-as-gw,availability-zones=az-0:az-1:az-2" + +.. end + +The above command is adding two configurations to the ``ovn-cms-options`` +option, the ``enable-chassis-as-gw`` option which tells the OVN driver +that this is a gateway/networker node and the ``availability-zones`` +option specifying three availability zones: **az-0**, **az-1** and +**az-2**. + +.. note:: + + Specifying the "enable-chassis-as-gw" option is not required for the + Availability Zones **however** ML2/OVN will only consider nodes that + are gateway (the ones with the "enable-chassis-as-gw" option) when + scheduling both ``router`` and ``external`` ports. So, even tho the + "availability-zones" option can be set own their own, the ML2/OVN + driver does not have a use case for it at the moment. + +.. end + +Note that, the syntax used to specify the availability zones is the +``availability-zones`` word, followed by an equal sign (=) and a +**colon** separated list of the availability zones that this local +``ovn-controller`` instance belongs to. + +To confirm the specific ``ovn-controller`` availability zones, check the +**Availability Zone** column in the output of the command below: + +.. code-block:: bash + + $ openstack network agent list + +--------------------------------------+------------------------------+----------------+-------------------+-------+-------+----------------+ + | ID | Agent Type | Host | Availability Zone | Alive | State | Binary | + +--------------------------------------+------------------------------+----------------+-------------------+-------+-------+----------------+ + | 2d1924b2-99a4-4c6c-a4f2-0be64c0cec8c | OVN Controller Gateway agent | gateway-host-0 | az0, az1, az2 | :-) | UP | ovn-controller | + +--------------------------------------+------------------------------+----------------+-------------------+-------+-------+----------------+ + +.. end + +.. note:: + + If you know the UUID of the agent the "**openstack network agent show + **" command can also be used. + +.. end + +To confirm the availability zones defined in the system as a whole: + +.. code-block:: bash + + $ openstack availability zone list --network + +-----------+-------------+ + | Zone Name | Zone Status | + +-----------+-------------+ + | az0 | available | + | az1 | available | + | az2 | available | + +-----------+-------------+ + +.. end + +Router Availability Zones +------------------------- + +In order to create a router with availability zones the +``--availability-zone-hint`` should be passed to the create command, +note that this parameter can be specified multiple times in case the +router belongs to more than one availability zone. For example: + +.. code-block:: bash + + $ openstack router create --availability-zone-hint az-0 --availability-zone-hint az-1 router-0 + +-------------------------+--------------------------------------+ + | Field | Value | + +-------------------------+--------------------------------------+ + | admin_state_up | UP | + | availability_zone_hints | az-0, az-1 | + | availability_zones | | + | created_at | 2020-06-04T08:29:33Z | + | description | | + | external_gateway_info | null | + | flavor_id | None | + | id | 8fd6d01a-57ad-4e91-a788-ebe48742d000 | + | name | router-0 | + | project_id | 2a364ced6c084888be0919450629de1c | + | revision_number | 1 | + | routes | | + | status | ACTIVE | + | tags | | + | updated_at | 2020-06-04T08:29:33Z | + +-------------------------+--------------------------------------+ + +.. end + +It's also possible to set the default availability zones via the +*/etc/neutron/neutron.conf* configuration file: + +.. code-block:: ini + + [DEFAULT] + default_availability_zones = az-0,az-2 + ... + +.. end + +When scheduling the gateway ports of a router, the OVN driver will take +into consideration the router availability zones and make sure that the +ports are scheduled on the nodes belonging to those availability zones. + +Note that in the router object we have two attributes +related to availability zones: ``availability_zones`` and +``availability_zone_hints``: + +.. code-block:: bash + + | availability_zone_hints | az-0, az-1 | + | availability_zones | | + +.. end + +This distinction makes more sense in the **ML2/OVS** driver which +relies on the L3 agent for its router placement (see the :ref:`ML2/OVS +driver Availability Zones guide` for more information). In +**ML2/OVN** the ``ovn-controller`` service will be running on all nodes +of the cluster so the ``availability_zone_hints`` will always match the +``availability_zones`` attribute, as below: + +.. code-block:: bash + + | availability_zone_hints | az-0, az-1 | + | availability_zones | az-0, az-1 | + +.. end + +OVN Database information +************************ + +In order to check the availability zones of a router +via the OVN Northbound database, one can look for the +``neutron:availability_zone_hints`` key in the ``external_ids`` +column for its entry in the ``Logical_Router`` table: + +.. code-block:: bash + + $ ovn-nbctl list Logical_Router + _uuid : 4df68f1e-17dd-4b9a-848d-b6152ae19203 + external_ids : {"neutron:availability_zone_hints"="az-0,az-1", "neutron:gw_port_id"="", "neutron:revision_number"="1", "neutron:router_name"=router-0} + name : neutron-8fd6d01a-57ad-4e91-a788-ebe48742d000 + ... + +.. end + + +To check the availability zones of the Chassis, look at the +``ovn-cms-options`` key in the ``other_config`` column (or +``external_ids`` for an older version of OVN) of the ``Chassis`` table +in the OVN Southbound database: + +.. code-block:: bash + + $ ovn-sbctl list Chassis + _uuid : abaa9f07-9988-40c0-bd1a-8d8326af08b0 + name : "2d1924b2-99a4-4c6c-a4f2-0be64c0cec8c" + other_config : {..., ovn-cms-options="enable-chassis-as-gw,availability-zones=az-0:az-1:az-2"} + ... + +.. end + +As mentioned in the `Router availability zones`_ section, the +scheduling of the gateway router ports will take into consideration +the availability zones that the router belongs to. We can confirm +this behavior by looking in the ``Gateway_Chassis`` table from the OVN +Northbound database: + +.. code-block:: bash + + $ ovn-nbctl list Gateway_Chassis + _uuid : ac61b70f-ff51-43d9-830b-f9bc6d74090a + chassis_name : "2d1924b2-99a4-4c6c-a4f2-0be64c0cec8c" + external_ids : {} + name : lrp-5a40eeca-5233-4029-a470-9018aa8b3de9_2d1924b2-99a4-4c6c-a4f2-0be64c0cec8c + options : {} + priority : 2 + + _uuid : c1b7763b-1784-4e5a-a948-853662faeddc + chassis_name : "1cde2542-69f9-4598-b20b-d4f68304deb0" + external_ids : {} + name : lrp-5a40eeca-5233-4029-a470-9018aa8b3de9_1cde2542-69f9-4598-b20b-d4f68304deb0 + options : {} + priority : 1 + +.. end + +Each entry on this table represents an instance of the gateway port +(L3 HA, for more information see :ref:`Routing in OVN`), +the ``chassis_name`` column indicates which Chassis that port instance +is scheduled onto. If we co-relate each entry and their ``chassis_name`` +we will see that this port has been only scheduled to Chassis matching +with the router's availability zones. + +Network Availability Zones +-------------------------- + +Since OVN has a distributed DHCP server model (see the +`ovn-architecture `_ +document for more information), one may think that there's no need +for Ml2/OVN to support Network Availability Zones as there's no need +to co-locate a DHCP agent within the same zones to serve the VMs but, +in ML2/OVN there's a special case which are the ``external`` ports and +those need to be aware of the Availability Zones for its scheduling. + +These ``external`` ports are ports that are located on a different +node than the one that the VM is running. At the moment, ML2/OVN only +supports one case that makes use of these ports which is the :ref:`SR-IOV +support`. + +In order to create a network with availability zones the +``--availability-zone-hint`` should be passed to the create command, +note that this parameter can be specified multiple times in case the +network belongs to more than one availability zone. For example: + +.. code-block:: bash + + $ openstack network create --availability-zone-hint az-0 --availability-zone-hint az-1 network-0 + +---------------------------+--------------------------------------+ + | Field | Value | + +---------------------------+--------------------------------------+ + | admin_state_up | UP | + | availability_zone_hints | az-0, az-1 | + | availability_zones | | + | created_at | 2021-04-26T14:04:51Z | + | description | | + | dns_domain | | + | id | ba584cdb-b866-4744-85d3-6e38718055cc | + | ipv4_address_scope | None | + | ipv6_address_scope | None | + | is_default | False | + | is_vlan_transparent | None | + | mtu | 1442 | + | name | network-0 | + | port_security_enabled | True | + | project_id | ffd9e4a60af34b0599f1d50aed20dde0 | + | provider:network_type | None | + | provider:physical_network | None | + | provider:segmentation_id | None | + | qos_policy_id | None | + | revision_number | 1 | + | router:external | Internal | + | segments | None | + | shared | False | + | status | ACTIVE | + | subnets | | + | tags | | + | updated_at | 2021-04-26T14:04:52Z | + +---------------------------+--------------------------------------+ + +.. end + +OVN Database information +************************ + +Upon creating the first ``external`` port to a network with Availability +Zones set a HA Chassis Group correspondent to that network will also be +created in the OVN Northbound Database: + +.. code-block:: bash + + $ openstack port create --network network-0 --vnic-type direct port-0 + +-------------------------+--------------------------------------+ + | Field | Value | + +-------------------------+--------------------------------------+ + | id | 2523d7f5-c7ca-40b8-83c5-ac37e5b126ea | + | name | port-0 | + | network_id | ba584cdb-b866-4744-85d3-6e38718055cc | + ... + +-------------------------+--------------------------------------+ +.. end + +To find the corresponding HA Chassis Group we need to look for a group +named as *neutron-*, for example: + +.. code-block:: bash + + $ ovn-nbctl list HA_Chassis_Group neutron-ba584cdb-b866-4744-85d3-6e38718055cc + _uuid : f6a49abb-dc97-4e2a-955a-6f8e8be4865e + external_ids : {"neutron:availability_zone_hints"="az-0,az-1"} + ha_chassis : [46850075-7383-4da9-b0b2-5ded2858f681, ce1da6a5-77d3-4945-b218-c0ae35403b80] + name : neutron-ba584cdb-b866-4744-85d3-6e38718055cc + +.. end + +In the output above is possible to see that the HA Chassis Group for +the Neutron network ``ba584cdb-b866-4744-85d3-6e38718055cc`` includes +two Chassis (the ``ha_chassis`` column) that are part of the Availability +Zones that this network is also part of. + +We can inspect these members to see which one has the **highest** +priority, which means that when the ``external`` port is bound it +will first bound to the HA Chassis with the **highest** priority in +the Group. In case that Chassis goes down the port will move on to the +next Chassis with the **highest** priority and so on. To check these HA +Chassis do: + +.. code-block:: bash + + $ ovn-nbctl list HA_Chassis 46850075-7383-4da9-b0b2-5ded2858f681 + _uuid : 46850075-7383-4da9-b0b2-5ded2858f681 + chassis_name : "2c5c4479-0e2b-4742-a1d7-df10be020143" + external_ids : {} + priority : 32766 + + $ ovn-nbctl list HA_Chassis ce1da6a5-77d3-4945-b218-c0ae35403b8 + _uuid : ce1da6a5-77d3-4945-b218-c0ae35403b80 + chassis_name : "159970f0-71f7-4d3d-9a9e-92e37c5f03c5" + external_ids : {} + priority : 32767 + +.. end + +In this case, the **active** Chassis is the +``159970f0-71f7-4d3d-9a9e-92e37c5f03c5``. + +And lastly, to find which HA Chassis Group an external +port belongs to by looking into the OVN Northbound Database do: + +.. code-block:: bash + + $ sudo ovn-nbctl list Logical_Switch_Port 2523d7f5-c7ca-40b8-83c5-ac37e5b126ea + _uuid : 382d8cd8-575f-4a3f-93ba-a01cb9c2c265 + ha_chassis_group : f6a49abb-dc97-4e2a-955a-6f8e8be4865e + name : "2523d7f5-c7ca-40b8-83c5-ac37e5b126ea" + type : external + ... + +.. end + +The ``ha_chassis_group`` column will point to the UUID (in the OVN +database) of the HA Chassis Group it belongs to. diff --git a/doc/source/admin/ovn/index.rst b/doc/source/admin/ovn/index.rst index 78814847291..371d0eda909 100644 --- a/doc/source/admin/ovn/index.rst +++ b/doc/source/admin/ovn/index.rst @@ -14,5 +14,5 @@ OVN Driver Administration Guide dpdk troubleshooting sriov - router_availability_zones + availability_zones routed_provider_networks diff --git a/doc/source/admin/ovn/router_availability_zones.rst b/doc/source/admin/ovn/router_availability_zones.rst deleted file mode 100644 index 1efb843d589..00000000000 --- a/doc/source/admin/ovn/router_availability_zones.rst +++ /dev/null @@ -1,208 +0,0 @@ -.. _ovn_router_availability_zones: - -======================================= -Router Availability Zones guide for OVN -======================================= - -The purpose of this page is to describe how the router availability zones -works with OVN. Prior to reading this document, it is recommended to first -read :ref:`ML2/OVS driver Availability Zones guide`. - -How to configure it -~~~~~~~~~~~~~~~~~~~ - -Different from the ML2/OVS driver for Neutron the availability zones for -the OVN driver is not configured via a configuration file. Since ML2/OVN -does not rely on an external agent such as the L3 agent, certain nodes -(e.g gateway/networker node) won't have any Neutron configuration file present. For -this reason, OVN uses the local OVSDB for configuring the availability -zones that instance of ``ovn-controller`` running on that hypervisor -belongs to. - -The configuration is done via the ``ovn-cms-options`` entry in -*external_ids* column of the local *Open_vSwitch* table: - -.. code-block:: bash - - $ ovs-vsctl set Open_vSwitch . external-ids:ovn-cms-options="enable-chassis-as-gw,availability-zones=az-0:az-1:az-2" - -.. end - -The above command is adding two configurations to the ``ovn-cms-options`` -option, the ``enable-chassis-as-gw`` option which tells the OVN driver -that this is a gateway/networker node and the ``availability-zones`` -option specifying three availability zones: **az-0**, **az-1** and -**az-2**. - -Note that, the syntax used to specify the availability zones is the -``availability-zones`` word, followed by an equal sign (=) and a -**colon** separated list of the availability zones that this local -``ovn-controller`` instance belongs to. - -To confirm the specific ``ovn-controller`` availability zones, check the -**Availability Zone** column in the output of the command below: - -.. code-block:: bash - - $ openstack network agent list - +--------------------------------------+------------------------------+----------------+-------------------+-------+-------+----------------+ - | ID | Agent Type | Host | Availability Zone | Alive | State | Binary | - +--------------------------------------+------------------------------+----------------+-------------------+-------+-------+----------------+ - | 2d1924b2-99a4-4c6c-a4f2-0be64c0cec8c | OVN Controller Gateway agent | gateway-host-0 | az0, az1, az2 | :-) | UP | ovn-controller | - +--------------------------------------+------------------------------+----------------+-------------------+-------+-------+----------------+ - -.. end - -.. note:: - - If you know the UUID of the agent the "**openstack network agent show - **" command can also be used. - -.. end - -To confirm the availability zones defined in the system as a whole: - -.. code-block:: bash - - $ openstack availability zone list - +-----------+-------------+ - | Zone Name | Zone Status | - +-----------+-------------+ - | az0 | available | - | az1 | available | - | az2 | available | - +-----------+-------------+ - -.. end - -Using router availability zones -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In order to create a router with availability zones the -``--availability-zone-hint`` should be passed to the create command, -note that this parameter can be specified multiple times in case the -router belongs to more than one availability zone. For example: - -.. code-block:: bash - - $ openstack router create --availability-zone-hint az-0 --availability-zone-hint az-1 router-0 - +-------------------------+--------------------------------------+ - | Field | Value | - +-------------------------+--------------------------------------+ - | admin_state_up | UP | - | availability_zone_hints | az-0, az-1 | - | availability_zones | | - | created_at | 2020-06-04T08:29:33Z | - | description | | - | external_gateway_info | null | - | flavor_id | None | - | id | 8fd6d01a-57ad-4e91-a788-ebe48742d000 | - | name | router-0 | - | project_id | 2a364ced6c084888be0919450629de1c | - | revision_number | 1 | - | routes | | - | status | ACTIVE | - | tags | | - | updated_at | 2020-06-04T08:29:33Z | - +-------------------------+--------------------------------------+ - -.. end - -It's also possible to set the default availability zones via the -*/etc/neutron/neutron.conf* configuration file: - -.. code-block:: ini - - [DEFAULT] - default_availability_zones = az-0,az-2 - ... - -.. end - -When scheduling the gateway ports of a router, the OVN driver will take -into consideration the router availability zones and make sure that the -ports are scheduled on the nodes belonging to those availability zones. - -Note that in the router object we have two attributes -related to availability zones: ``availability_zones`` and -``availability_zone_hints``: - -.. code-block:: bash - - | availability_zone_hints | az-0, az-1 | - | availability_zones | | - -.. end - -This distinction makes more sense in the **ML2/OVS** driver which -relies on the L3 agent for its router placement (see the :ref:`ML2/OVS -driver Availability Zones guide` for more information). In -**ML2/OVN** the ``ovn-controller`` service will be running on all nodes -of the cluster so the ``availability_zone_hints`` will always match the -``availability_zones`` attribute. - -OVN Database information -~~~~~~~~~~~~~~~~~~~~~~~~ - -In order to check the availability zones of a router -via the OVN Northbound database, one can look for the -``neutron:availability_zone_hints`` key in the ``external_ids`` -column for its entry in the ``Logical_Router`` table: - -.. code-block:: bash - - $ ovn-nbctl list Logical_Router - _uuid : 4df68f1e-17dd-4b9a-848d-b6152ae19203 - external_ids : {"neutron:availability_zone_hints"="az-0,az-1", "neutron:gw_port_id"="", "neutron:revision_number"="1", "neutron:router_name"=router-0} - name : neutron-8fd6d01a-57ad-4e91-a788-ebe48742d000 - ... - -.. end - - -To check the availability zones of the Chassis, look at the -``ovn-cms-options`` key in the ``other_config`` column (or -``external_ids`` for an older version of OVN) of the ``Chassis`` table -in the OVN Southbound database: - -.. code-block:: bash - - $ ovn-sbctl list Chassis - _uuid : abaa9f07-9988-40c0-bd1a-8d8326af08b0 - name : "2d1924b2-99a4-4c6c-a4f2-0be64c0cec8c" - other_config : {..., ovn-cms-options="enable-chassis-as-gw,availability-zones=az-0:az-1:az-2"} - ... - -.. end - -As mentioned in the `Using router availability zones`_ section, the -scheduling of the gateway router ports will take into consideration -the availability zones that the router belongs to. We can confirm -this behavior by looking in the ``Gateway_Chassis`` table from the OVN -Southbound database: - -.. code-block:: bash - - $ ovn-sbctl list Gateway_Chassis - _uuid : ac61b70f-ff51-43d9-830b-f9bc6d74090a - chassis_name : "2d1924b2-99a4-4c6c-a4f2-0be64c0cec8c" - external_ids : {} - name : lrp-5a40eeca-5233-4029-a470-9018aa8b3de9_2d1924b2-99a4-4c6c-a4f2-0be64c0cec8c - options : {} - priority : 2 - - _uuid : c1b7763b-1784-4e5a-a948-853662faeddc - chassis_name : "1cde2542-69f9-4598-b20b-d4f68304deb0" - external_ids : {} - name : lrp-5a40eeca-5233-4029-a470-9018aa8b3de9_1cde2542-69f9-4598-b20b-d4f68304deb0 - options : {} - priority : 1 - -.. end - -Each entry on this table represents an instance of the gateway port -(L3 HA, for more information see :ref:`Routing in OVN`), -the ``chassis_name`` column indicates which Chassis that port instance -is scheduled onto. If we co-relate each entry and their ``chassis_name`` -we will see that this port has been only scheduled to Chassis matching -with the router's availability zones. diff --git a/doc/source/admin/ovn/sriov.rst b/doc/source/admin/ovn/sriov.rst index caee63f7337..89dac9c9ba3 100644 --- a/doc/source/admin/ovn/sriov.rst +++ b/doc/source/admin/ovn/sriov.rst @@ -112,22 +112,22 @@ port belongs to, to find that group do: _uuid : 43047e7b-4c78-4984-9788-6263fcc69885 external_ids : {} ha_chassis : [3005bf84-fc95-4361-866d-bfa1c980adc8, 72c7671e-dd48-4100-9741-c47221672961] - name : default_ha_chassis_group + name : neutron-4b2944ca-c7a3-4cf6-a9c8-6aa541a20535 .. end .. note:: + The external ports will be placed on a HA Chassis Group for the + network that the port belongs to. Those HA Chassis Groups are named as + ``neutron-``, as seeing in the output above. You + can also use this "name" with the ``ovn-nbctl list`` command when + searching for a specific HA Chassis Group. - For now, the OVN driver only has one HA Chassis Group created called - ``default_ha_chassis_group``. All ``external`` ports in the system - will belong to this group. - -The chassis that are members of the ``default_ha_chassis_group`` HA -Chassis Group are listed in the ``ha_chassis`` column. Those are the -gateway nodes (controller or networker nodes) in the deployment and -it's where the ``external`` ports will be scheduled. In order to -find which gateway node the external ports are scheduled on use the -following command: +The chassis that are members of the HA Chassis Group are listed in +the ``ha_chassis`` column. Those are the gateway nodes (controller +or networker nodes) in the deployment and it's where the ``external`` +ports will be scheduled. In order to find which gateway node the external +ports are scheduled on use the following command: .. code-block:: bash @@ -161,10 +161,6 @@ Known limitations The current SR-IOV implementation for the OVN Neutron driver has a few known limitations that should be addressed in the future: -#. At the moment, **all** external ports will be scheduled on a single - gateway node since there's only one HA Chassis Group for all of those - ports. - #. Routing on VLAN tenant network will not work with SR-IOV. This is because the external ports are not being co-located with the logical router's gateway ports, for more information take a look at diff --git a/doc/source/ovn/gaps.rst b/doc/source/ovn/gaps.rst index 02bfc597ce7..6d839b840c0 100644 --- a/doc/source/ovn/gaps.rst +++ b/doc/source/ovn/gaps.rst @@ -39,27 +39,16 @@ at [1]_. (no. 175). Also, Ironic uses dnsmasq syntax when configuring the DHCP options for Neutron [5]_ which is not understood by the OVN driver. -* Availability Zones - - Availability zones are used to make network resources highly available - by grouping nodes in separate zones which resources will be scheduled - to. Neutron supports two types of availability zones: Network (DHCP - agent) and router (L3 agent). The OVN team needs to assess each case - to see how they would fit in the OVN model. For example, in the router - availability zone case, the OVN driver should schedule the router - ports on a Chassis (a "node" in OVN terms) where the availability - zones match with the router availability zones [6]_. - * QoS minimum bandwidth allocation in Placement API ML2/OVN integration with the Nova placement API to provide guaranteed - minimum bandwidth for ports [7]_. + minimum bandwidth for ports [6]_. * IPv6 Prefix Delegation Currently ML2/OVN doesn't implement IPv6 prefix delegation. OVN logical - routers have this capability implemented in [8]_ and we have an open RFE to - fill this gap [9]_. + routers have this capability implemented in [7]_ and we have an open RFE to + fill this gap [8]_. * East/West Fragmentation @@ -76,7 +65,6 @@ References .. [3] https://github.com/openvswitch/ovs/commit/66d89287269ca7e2f7593af0920e910d7f9bcc38 .. [4] https://github.com/torvalds/linux/blob/master/net/openvswitch/meter.h .. [5] https://github.com/openstack/ironic/blob/123cb22c731f93d0c608d791b41e05884fe18c04/ironic/common/pxe_utils.py#L447-L462> -.. [6] https://docs.openstack.org/neutron/latest/admin/config-az.html -.. [7] https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html -.. [8] https://patchwork.ozlabs.org/project/openvswitch/patch/6aec0fb280f610a2083fbb6c61e251b1d237b21f.1576840560.git.lorenzo.bianconi@redhat.com/ -.. [9] https://bugs.launchpad.net/neutron/+bug/1895972 +.. [6] https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html +.. [7] https://patchwork.ozlabs.org/project/openvswitch/patch/6aec0fb280f610a2083fbb6c61e251b1d237b21f.1576840560.git.lorenzo.bianconi@redhat.com/ +.. [8] https://bugs.launchpad.net/neutron/+bug/1895972 diff --git a/releasenotes/notes/ovn-network-az-c4ee9a4089872818.yaml b/releasenotes/notes/ovn-network-az-c4ee9a4089872818.yaml new file mode 100644 index 00000000000..e24362170f1 --- /dev/null +++ b/releasenotes/notes/ovn-network-az-c4ee9a4089872818.yaml @@ -0,0 +1,10 @@ +--- +features: + - | + Adds support for Network Availability Zones to the OVN driver. When + Network AZ is used, OVN's "external" ports will now be scheduled + onto nodes belonging to the AZs specified in the network that the + port belongs to. This feature also removes the limitation where all + "external" ports were part of to a single HA Chassis Group (meaning + they would all be bond to a single host) now the "external" ports + will be better distributed across different hosts.