From 6cf2b026a5604f0b151969169b0195f737a3836c Mon Sep 17 00:00:00 2001 From: Massimiliano Favaro-Bedford <78351765+MaxBed4d@users.noreply.github.com> Date: Fri, 30 Aug 2024 11:23:19 +0100 Subject: [PATCH 01/10] Update octavia.rst Updating the Octavia docs to explain how to deploy it, alongside other important settings. --- doc/source/operations/octavia.rst | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/doc/source/operations/octavia.rst b/doc/source/operations/octavia.rst index f884d130f..c7c3fe9d6 100644 --- a/doc/source/operations/octavia.rst +++ b/doc/source/operations/octavia.rst @@ -2,6 +2,29 @@ Octavia ======= +.. _Deploying Octavia: + +Deploying Octavia +================= + +Much like any other Kolla managed service, the method of deploying Octavia is as simple +as enabling ``kolla_enable_octavia: true`` within the chosen environment's ``kolla.yml``. +However, before running a ``kayobe overcloud service configure``, check +``octavia_net_interface`` (often found within the ``controllers`` directory within +``group_vars``) to see the network which Octavia management network will be using. +If it is configured to use a VLAN then ``kolla_enable_neutron_provider_networks: true`` +should also be set in ``kolla.yml``. + +.. note:: + + It of course goes without saying that the network configured for ``octavia_net_interface`` + should also exist in ``networks.yml``. + +By default Octavia will deploy a single Amphora VM per load balancing service, this should be +changed to make them highly available and have two Amphora VM per service. Done by setting +``octavia_loadbalancer_topology: "ACTIVE_STANDBY"``, this will ensure that if an Amphora VM +were to go down, the other would be able to take over the load balancing functions. + .. _Amphora image: Building and rotating amphora images From 413cf1bed8e72cfd57828846aec958c52e55057c Mon Sep 17 00:00:00 2001 From: Massimiliano Favaro-Bedford <78351765+MaxBed4d@users.noreply.github.com> Date: Fri, 30 Aug 2024 11:26:57 +0100 Subject: [PATCH 02/10] Update octavia.rst More changes to the docs. --- doc/source/operations/octavia.rst | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/doc/source/operations/octavia.rst b/doc/source/operations/octavia.rst index c7c3fe9d6..dce1740f3 100644 --- a/doc/source/operations/octavia.rst +++ b/doc/source/operations/octavia.rst @@ -2,6 +2,13 @@ Octavia ======= +.. Introduction to Octavia: + +Introduction to Octavia +======================= + +Octavia is known as an *operator-scaled* load balancing service. + .. _Deploying Octavia: Deploying Octavia @@ -22,8 +29,8 @@ should also be set in ``kolla.yml``. By default Octavia will deploy a single Amphora VM per load balancing service, this should be changed to make them highly available and have two Amphora VM per service. Done by setting -``octavia_loadbalancer_topology: "ACTIVE_STANDBY"``, this will ensure that if an Amphora VM -were to go down, the other would be able to take over the load balancing functions. +``octavia_loadbalancer_topology: "ACTIVE_STANDBY"``, this will ensure that if the master +Amphora VM were to go down, the other would be able to take over the load balancing functions. .. _Amphora image: From 9b6d6d5c1ad5b0232829c527a04018c6b934051d Mon Sep 17 00:00:00 2001 From: "max.bed4d" Date: Tue, 5 Nov 2024 13:36:42 +0000 Subject: [PATCH 03/10] provide path to set high availability for Amphora --- doc/source/operations/octavia.rst | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/doc/source/operations/octavia.rst b/doc/source/operations/octavia.rst index dce1740f3..942f99257 100644 --- a/doc/source/operations/octavia.rst +++ b/doc/source/operations/octavia.rst @@ -7,30 +7,31 @@ Octavia Introduction to Octavia ======================= -Octavia is known as an *operator-scaled* load balancing service. +Octavia is known as an *operator-scaled* load balancing service. .. _Deploying Octavia: Deploying Octavia ================= -Much like any other Kolla managed service, the method of deploying Octavia is as simple +Much like any other Kolla managed service, the method of deploying Octavia is as simple as enabling ``kolla_enable_octavia: true`` within the chosen environment's ``kolla.yml``. -However, before running a ``kayobe overcloud service configure``, check -``octavia_net_interface`` (often found within the ``controllers`` directory within -``group_vars``) to see the network which Octavia management network will be using. +However, before running a ``kayobe overcloud service configure``, check +``octavia_net_interface`` (often found within the ``controllers`` directory within +``group_vars``) to see the network which Octavia management network will be using. If it is configured to use a VLAN then ``kolla_enable_neutron_provider_networks: true`` should also be set in ``kolla.yml``. .. note:: - It of course goes without saying that the network configured for ``octavia_net_interface`` + It of course goes without saying that the network configured for ``octavia_net_interface`` should also exist in ``networks.yml``. -By default Octavia will deploy a single Amphora VM per load balancing service, this should be -changed to make them highly available and have two Amphora VM per service. Done by setting -``octavia_loadbalancer_topology: "ACTIVE_STANDBY"``, this will ensure that if the master -Amphora VM were to go down, the other would be able to take over the load balancing functions. +By default Octavia will deploy a single Amphora VM per load balancing service, this should be +changed to make them highly available and have two Amphora VM per service. Done by setting +``octavia_loadbalancer_topology: "ACTIVE_STANDBY"`` in ``${KAYOBE_CONFIG_PATH}/kolla/globals.yml``, +this will ensure that if the master Amphora VM were to go down, the other would be able to +take over the load balancing functions. .. _Amphora image: From a1705c0f315d61bda5a0fa5be1f09d22cd1e7656 Mon Sep 17 00:00:00 2001 From: "max.bed4d" Date: Tue, 5 Nov 2024 14:30:34 +0000 Subject: [PATCH 04/10] Add introduction and link to official docs --- doc/source/operations/octavia.rst | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/doc/source/operations/octavia.rst b/doc/source/operations/octavia.rst index 942f99257..707950e39 100644 --- a/doc/source/operations/octavia.rst +++ b/doc/source/operations/octavia.rst @@ -7,7 +7,12 @@ Octavia Introduction to Octavia ======================= -Octavia is known as an *operator-scaled* load balancing service. +Octavia is known as an *operator-scaled* load balancing service, whose primary goal is to +distribute incoming network traffic, destined for a single VM, across multiple VMs instead; +thus preventing overloading the VM and improving the overall performance of the VM's outbound +service. + +For more information on Octavia, please refer to the `official documentation `_. .. _Deploying Octavia: @@ -18,8 +23,8 @@ Much like any other Kolla managed service, the method of deploying Octavia is as as enabling ``kolla_enable_octavia: true`` within the chosen environment's ``kolla.yml``. However, before running a ``kayobe overcloud service configure``, check ``octavia_net_interface`` (often found within the ``controllers`` directory within -``group_vars``) to see the network which Octavia management network will be using. -If it is configured to use a VLAN then ``kolla_enable_neutron_provider_networks: true`` +``${KAYOBE_CONFIG_PATH}/inventory/group_vars``) to see the network which Octavia management +network will be using. If it is configured to use a VLAN then ``kolla_enable_neutron_provider_networks: true`` should also be set in ``kolla.yml``. .. note:: @@ -27,12 +32,15 @@ should also be set in ``kolla.yml``. It of course goes without saying that the network configured for ``octavia_net_interface`` should also exist in ``networks.yml``. -By default Octavia will deploy a single Amphora VM per load balancing service, this should be +By default Octavia will deploy an Amphorae (a single Amphora VM) per load balancing service, this should be changed to make them highly available and have two Amphora VM per service. Done by setting ``octavia_loadbalancer_topology: "ACTIVE_STANDBY"`` in ``${KAYOBE_CONFIG_PATH}/kolla/globals.yml``, this will ensure that if the master Amphora VM were to go down, the other would be able to take over the load balancing functions. +Further configuration options and details on installation can be found in the +`Octavia documentation `_. + .. _Amphora image: Building and rotating amphora images From 2cb2eac2fc62dbd6b5ef5822cb344f6a0357fc45 Mon Sep 17 00:00:00 2001 From: Massimiliano Favaro-Bedford <78351765+MaxBed4d@users.noreply.github.com> Date: Wed, 6 Nov 2024 10:10:56 +0000 Subject: [PATCH 05/10] Grammar fix Co-authored-by: Matt Crees --- doc/source/operations/octavia.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/source/operations/octavia.rst b/doc/source/operations/octavia.rst index 707950e39..864ad39ae 100644 --- a/doc/source/operations/octavia.rst +++ b/doc/source/operations/octavia.rst @@ -32,7 +32,7 @@ should also be set in ``kolla.yml``. It of course goes without saying that the network configured for ``octavia_net_interface`` should also exist in ``networks.yml``. -By default Octavia will deploy an Amphorae (a single Amphora VM) per load balancing service, this should be +By default Octavia will deploy an Amphora (a single Ubuntu VM running HAProxy) per load balancing service. This should be changed to make them highly available and have two Amphora VM per service. Done by setting ``octavia_loadbalancer_topology: "ACTIVE_STANDBY"`` in ``${KAYOBE_CONFIG_PATH}/kolla/globals.yml``, this will ensure that if the master Amphora VM were to go down, the other would be able to From a87a01384250c03cd9cb92281ea1b17f85700b90 Mon Sep 17 00:00:00 2001 From: Massimiliano Favaro-Bedford <78351765+MaxBed4d@users.noreply.github.com> Date: Wed, 6 Nov 2024 10:11:57 +0000 Subject: [PATCH 06/10] Update Octavia doc URL Co-authored-by: Alex-Welsh <112560678+Alex-Welsh@users.noreply.github.com> --- doc/source/operations/octavia.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/source/operations/octavia.rst b/doc/source/operations/octavia.rst index 864ad39ae..29bd79531 100644 --- a/doc/source/operations/octavia.rst +++ b/doc/source/operations/octavia.rst @@ -39,7 +39,7 @@ this will ensure that if the master Amphora VM were to go down, the other would take over the load balancing functions. Further configuration options and details on installation can be found in the -`Octavia documentation `_. +`Octavia documentation `_. .. _Amphora image: From 96895b686073511712fc9cb55381b7616ccb368f Mon Sep 17 00:00:00 2001 From: Massimiliano Favaro-Bedford <78351765+MaxBed4d@users.noreply.github.com> Date: Wed, 6 Nov 2024 10:22:27 +0000 Subject: [PATCH 07/10] Update Amphora high availability wording --- doc/source/operations/octavia.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/source/operations/octavia.rst b/doc/source/operations/octavia.rst index 29bd79531..a2c795151 100644 --- a/doc/source/operations/octavia.rst +++ b/doc/source/operations/octavia.rst @@ -32,11 +32,11 @@ should also be set in ``kolla.yml``. It of course goes without saying that the network configured for ``octavia_net_interface`` should also exist in ``networks.yml``. -By default Octavia will deploy an Amphora (a single Ubuntu VM running HAProxy) per load balancing service. This should be -changed to make them highly available and have two Amphora VM per service. Done by setting -``octavia_loadbalancer_topology: "ACTIVE_STANDBY"`` in ``${KAYOBE_CONFIG_PATH}/kolla/globals.yml``, -this will ensure that if the master Amphora VM were to go down, the other would be able to -take over the load balancing functions. +By default Octavia will deploy an Amphora (a single Ubuntu VM running HAProxy) per load balancing service. +Consequently, if using Amphora this default behaviour should be changed to make them highly available so that +there are two Amphora VMs per service. Done by setting ``octavia_loadbalancer_topology: "ACTIVE_STANDBY"`` +in ``${KAYOBE_CONFIG_PATH}/kolla/globals.yml``, this will ensure that if the master Amphora VM were to go down, +the other would be able to take over the load balancing functions. Further configuration options and details on installation can be found in the `Octavia documentation `_. From 79bbd3da1349fa18e93cfba761aac81cf6de39cc Mon Sep 17 00:00:00 2001 From: "max.bed4d" Date: Thu, 7 Nov 2024 13:15:33 +0000 Subject: [PATCH 08/10] make list of instructions --- doc/source/operations/octavia.rst | 63 ++++++++++++++++++++++--------- 1 file changed, 46 insertions(+), 17 deletions(-) diff --git a/doc/source/operations/octavia.rst b/doc/source/operations/octavia.rst index a2c795151..a27c972c2 100644 --- a/doc/source/operations/octavia.rst +++ b/doc/source/operations/octavia.rst @@ -20,23 +20,52 @@ Deploying Octavia ================= Much like any other Kolla managed service, the method of deploying Octavia is as simple -as enabling ``kolla_enable_octavia: true`` within the chosen environment's ``kolla.yml``. -However, before running a ``kayobe overcloud service configure``, check -``octavia_net_interface`` (often found within the ``controllers`` directory within -``${KAYOBE_CONFIG_PATH}/inventory/group_vars``) to see the network which Octavia management -network will be using. If it is configured to use a VLAN then ``kolla_enable_neutron_provider_networks: true`` -should also be set in ``kolla.yml``. - -.. note:: - - It of course goes without saying that the network configured for ``octavia_net_interface`` - should also exist in ``networks.yml``. - -By default Octavia will deploy an Amphora (a single Ubuntu VM running HAProxy) per load balancing service. -Consequently, if using Amphora this default behaviour should be changed to make them highly available so that -there are two Amphora VMs per service. Done by setting ``octavia_loadbalancer_topology: "ACTIVE_STANDBY"`` -in ``${KAYOBE_CONFIG_PATH}/kolla/globals.yml``, this will ensure that if the master Amphora VM were to go down, -the other would be able to take over the load balancing functions. +as: + +#. Enabling ``kolla_enable_octavia: true`` within the chosen environment's ``kolla.yml``. + +#. Check ``octavia_net_interface`` is configured in ``${KAYOBE_CONFIG_PATH}/inventory/group_vars/`` (often in ``controllers/network-interfaces.yml``). + + - IF NOT CONFIGURED + + 2.1. Check if a ``bond_interface`` has been configured, still within ``network-interfaces.yml``. + + 2.2. Check whether other network interfaces, such as ``internal_interface``, are configured to use ``{{ bond_interface }}`` and/or ``{{ .._vlan }}``. + + 2.3. If they are, then ``octavia_net_interface: "{{ brbond0_interface }}.{{ octavia_net`` ± ``_vlan }}"``. + + - IF CONFIGURED + + 2.1. Continue to step 3. + +#. Check that the ``{{ .._net_.. }}`` network configured for ``octavia_net_interface`` exists in ``networks.yml``. + + - IF NOT CONFIGURED + + 3.1. Set ``octavia_net_name: octavia_net``. + + 3.2. Configure the Octavia network IP information, making sure to set ``octavia_net_vlan`` if using a VLAN. + + - IF CONFIGURED + + 3.1. Continue to step 4. + +#. Dependencies if: + + - USING VLAN + + 4.1. Set ``kolla_enable_neutron_provider_networks: true`` in ``kolla.yml``. + + - USING AMPHORA + + 4.1. Set ``octavia_loadbalancer_topology: "ACTIVE_STANDBY"`` in ``${KAYOBE_CONFIG_PATH}/kolla/globals.yml``. + +#. Run ``kayobe overcloud service configure``. + +By default Octavia will deploy an Amphora (a single Ubuntu VM running HAProxy) per load balancing service. +Consequently, if using Amphora, this default behaviour should be changed to make them highly available so that +there are two Amphora VMs per service. Achieved by step 4.2 above, this will ensure that if the master Amphora +VM were to go down, the other would be able to take over the load balancing functions. Further configuration options and details on installation can be found in the `Octavia documentation `_. From ac0c3cc93f04caad36222ac0fdff10358b328237 Mon Sep 17 00:00:00 2001 From: Massimiliano Favaro-Bedford <78351765+MaxBed4d@users.noreply.github.com> Date: Tue, 26 Nov 2024 09:48:20 +0000 Subject: [PATCH 09/10] Update doc/source/operations/octavia.rst Co-authored-by: Matt Crees --- doc/source/operations/octavia.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/source/operations/octavia.rst b/doc/source/operations/octavia.rst index a27c972c2..07d561e55 100644 --- a/doc/source/operations/octavia.rst +++ b/doc/source/operations/octavia.rst @@ -60,7 +60,7 @@ as: 4.1. Set ``octavia_loadbalancer_topology: "ACTIVE_STANDBY"`` in ``${KAYOBE_CONFIG_PATH}/kolla/globals.yml``. -#. Run ``kayobe overcloud service configure``. +#. Run ``kayobe overcloud service reconfigure``. By default Octavia will deploy an Amphora (a single Ubuntu VM running HAProxy) per load balancing service. Consequently, if using Amphora, this default behaviour should be changed to make them highly available so that From 0277b00502adb3718f682cef8c867b3d38a5b7e7 Mon Sep 17 00:00:00 2001 From: Matt Anson Date: Wed, 12 Mar 2025 11:26:27 +0000 Subject: [PATCH 10/10] Linter fails in octavia.rst --- doc/source/operations/octavia.rst | 40 +++++++++++++++---------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/doc/source/operations/octavia.rst b/doc/source/operations/octavia.rst index 1978d3912..56198102a 100644 --- a/doc/source/operations/octavia.rst +++ b/doc/source/operations/octavia.rst @@ -26,38 +26,38 @@ as: #. Check ``octavia_net_interface`` is configured in ``${KAYOBE_CONFIG_PATH}/inventory/group_vars/`` (often in ``controllers/network-interfaces.yml``). - - IF NOT CONFIGURED + - IF NOT CONFIGURED - 2.1. Check if a ``bond_interface`` has been configured, still within ``network-interfaces.yml``. + 2.1. Check if a ``bond_interface`` has been configured, still within ``network-interfaces.yml``. - 2.2. Check whether other network interfaces, such as ``internal_interface``, are configured to use ``{{ bond_interface }}`` and/or ``{{ .._vlan }}``. - - 2.3. If they are, then ``octavia_net_interface: "{{ brbond0_interface }}.{{ octavia_net`` ± ``_vlan }}"``. + 2.2. Check whether other network interfaces, such as ``internal_interface``, are configured to use ``{{ bond_interface }}`` and/or ``{{ .._vlan }}``. - - IF CONFIGURED + 2.3. If they are, then ``octavia_net_interface: "{{ brbond0_interface }}.{{ octavia_net`` ± ``_vlan }}"``. + + - IF CONFIGURED 2.1. Continue to step 3. -#. Check that the ``{{ .._net_.. }}`` network configured for ``octavia_net_interface`` exists in ``networks.yml``. +#. Check that the ``{{ .._net_.. }}`` network configured for ``octavia_net_interface`` exists in ``networks.yml``. + + - IF NOT CONFIGURED + + 3.1. Set ``octavia_net_name: octavia_net``. - - IF NOT CONFIGURED + 3.2. Configure the Octavia network IP information, making sure to set ``octavia_net_vlan`` if using a VLAN. + + - IF CONFIGURED - 3.1. Set ``octavia_net_name: octavia_net``. - - 3.2. Configure the Octavia network IP information, making sure to set ``octavia_net_vlan`` if using a VLAN. - - - IF CONFIGURED - 3.1. Continue to step 4. -#. Dependencies if: +#. Dependencies if: + + - USING VLAN + + 4.1. Set ``kolla_enable_neutron_provider_networks: true`` in ``kolla.yml``. - - USING VLAN + - USING AMPHORA - 4.1. Set ``kolla_enable_neutron_provider_networks: true`` in ``kolla.yml``. - - - USING AMPHORA - 4.1. Set ``octavia_loadbalancer_topology: "ACTIVE_STANDBY"`` in ``${KAYOBE_CONFIG_PATH}/kolla/globals.yml``. #. Run ``kayobe overcloud service reconfigure``.