Skip to content

Commit 79bbd3d

Browse files
committed
make list of instructions
1 parent 96895b6 commit 79bbd3d

File tree

1 file changed

+46
-17
lines changed

1 file changed

+46
-17
lines changed

doc/source/operations/octavia.rst

+46-17
Original file line numberDiff line numberDiff line change
@@ -20,23 +20,52 @@ Deploying Octavia
2020
=================
2121

2222
Much like any other Kolla managed service, the method of deploying Octavia is as simple
23-
as enabling ``kolla_enable_octavia: true`` within the chosen environment's ``kolla.yml``.
24-
However, before running a ``kayobe overcloud service configure``, check
25-
``octavia_net_interface`` (often found within the ``controllers`` directory within
26-
``${KAYOBE_CONFIG_PATH}/inventory/group_vars``) to see the network which Octavia management
27-
network will be using. If it is configured to use a VLAN then ``kolla_enable_neutron_provider_networks: true``
28-
should also be set in ``kolla.yml``.
29-
30-
.. note::
31-
32-
It of course goes without saying that the network configured for ``octavia_net_interface``
33-
should also exist in ``networks.yml``.
34-
35-
By default Octavia will deploy an Amphora (a single Ubuntu VM running HAProxy) per load balancing service.
36-
Consequently, if using Amphora this default behaviour should be changed to make them highly available so that
37-
there are two Amphora VMs per service. Done by setting ``octavia_loadbalancer_topology: "ACTIVE_STANDBY"``
38-
in ``${KAYOBE_CONFIG_PATH}/kolla/globals.yml``, this will ensure that if the master Amphora VM were to go down,
39-
the other would be able to take over the load balancing functions.
23+
as:
24+
25+
#. Enabling ``kolla_enable_octavia: true`` within the chosen environment's ``kolla.yml``.
26+
27+
#. Check ``octavia_net_interface`` is configured in ``${KAYOBE_CONFIG_PATH}/inventory/group_vars/`` (often in ``controllers/network-interfaces.yml``).
28+
29+
- IF NOT CONFIGURED
30+
31+
2.1. Check if a ``bond_interface`` has been configured, still within ``network-interfaces.yml``.
32+
33+
2.2. Check whether other network interfaces, such as ``internal_interface``, are configured to use ``{{ bond_interface }}`` and/or ``{{ .._vlan }}``.
34+
35+
2.3. If they are, then ``octavia_net_interface: "{{ brbond0_interface }}.{{ octavia_net`` ± ``_vlan }}"``.
36+
37+
- IF CONFIGURED
38+
39+
2.1. Continue to step 3.
40+
41+
#. Check that the ``{{ .._net_.. }}`` network configured for ``octavia_net_interface`` exists in ``networks.yml``.
42+
43+
- IF NOT CONFIGURED
44+
45+
3.1. Set ``octavia_net_name: octavia_net``.
46+
47+
3.2. Configure the Octavia network IP information, making sure to set ``octavia_net_vlan`` if using a VLAN.
48+
49+
- IF CONFIGURED
50+
51+
3.1. Continue to step 4.
52+
53+
#. Dependencies if:
54+
55+
- USING VLAN
56+
57+
4.1. Set ``kolla_enable_neutron_provider_networks: true`` in ``kolla.yml``.
58+
59+
- USING AMPHORA
60+
61+
4.1. Set ``octavia_loadbalancer_topology: "ACTIVE_STANDBY"`` in ``${KAYOBE_CONFIG_PATH}/kolla/globals.yml``.
62+
63+
#. Run ``kayobe overcloud service configure``.
64+
65+
By default Octavia will deploy an Amphora (a single Ubuntu VM running HAProxy) per load balancing service.
66+
Consequently, if using Amphora, this default behaviour should be changed to make them highly available so that
67+
there are two Amphora VMs per service. Achieved by step 4.2 above, this will ensure that if the master Amphora
68+
VM were to go down, the other would be able to take over the load balancing functions.
4069

4170
Further configuration options and details on installation can be found in the
4271
`Octavia documentation <https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html>`_.

0 commit comments

Comments
 (0)