Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update octavia.rst #1362

Open
wants to merge 9 commits into
base: stackhpc/2024.1
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 68 additions & 0 deletions doc/source/operations/octavia.rst
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,74 @@
Octavia
=======

.. Introduction to Octavia:

Introduction to Octavia
=======================

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 <https://docs.openstack.org/octavia/latest/reference/introduction.html>`_.

.. _Deploying Octavia:

Deploying Octavia
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you restructure this into a sequence of individual steps? See for example the Multinode page which goes through a few things step-by-step

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems a little unnecessary for this because it would end up being 2 steps; this is more to make people aware of the various configs which could snag the deployment.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think at the moment it misses a few important steps, in particular "It of course goes without saying that the network should exist in networks.yml" is a pretty big thing to gloss over.

So for example you could have:

  1. Where to enable the service in kolla.yml
  2. How to define the octavia network in networks.yml
  3. How to define network interfaces for controllers
  4. What to check for neutron provider networks
  5. How to select the right driver(s), and the differences between Amphora vs OVN
  6. How to properly configure the Amphora driver

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also keep in mind that simple, clear instructions make for the best docs. try to stay away from wordyness.

For example:

Much like any other Kolla managed service, the method of deploying Octavia is as simple
as ...

could be written as:

To enable Octavia, set ...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have an idea on how to make a nice comprehensive list. Regarding the wordyness, in some cases it is intentional, in the example provided mentioning its similarity to other Kolla managed services will give users a lot of context as to what to expect, as long as they have deployed at least one service before; in addition to reinforcing the steps for deploying services. In other cases, I agree and some sentences are wordy without adding anything.

=================

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``.

#. 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 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
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 <https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html>`_.

.. _Amphora image:

Building and rotating amphora images
Expand Down
Loading