-
Notifications
You must be signed in to change notification settings - Fork 20
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
base: stackhpc/2024.1
Are you sure you want to change the base?
Update octavia.rst #1362
Conversation
Updating the Octavia docs to explain how to deploy it, alongside other important settings.
More changes to the docs.
|
||
.. _Deploying Octavia: | ||
|
||
Deploying Octavia |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
- Where to enable the service in kolla.yml
- How to define the octavia network in networks.yml
- How to define network interfaces for controllers
- What to check for neutron provider networks
- How to select the right driver(s), and the differences between Amphora vs OVN
- How to properly configure the Amphora driver
There was a problem hiding this comment.
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 ...
There was a problem hiding this comment.
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.
Co-authored-by: Matt Crees <[email protected]>
Co-authored-by: Alex-Welsh <[email protected]>
947d6f0
to
a2f07d0
Compare
a2f07d0
to
79bbd3d
Compare
|
||
4.1. Set ``octavia_loadbalancer_topology: "ACTIVE_STANDBY"`` in ``${KAYOBE_CONFIG_PATH}/kolla/globals.yml``. | ||
|
||
#. Run ``kayobe overcloud service configure``. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#. Run ``kayobe overcloud service configure``. | |
#. Run ``kayobe overcloud service reconfigure``. |
Update to the Octavia docs to provide some details on the deployment.