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 4 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
39 changes: 39 additions & 0 deletions doc/source/operations/octavia.rst
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,45 @@
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``.
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 Amphorae (a single Amphora VM) per load balancing service, this should be
MaxBed4d marked this conversation as resolved.
Show resolved Hide resolved
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.
MaxBed4d marked this conversation as resolved.
Show resolved Hide resolved

Further configuration options and details on installation can be found in the
`Octavia documentation <https://docs.openstack.org/octavia/latest/install/index.html>`_.
MaxBed4d marked this conversation as resolved.
Show resolved Hide resolved

.. _Amphora image:

Building and rotating amphora images
Expand Down