Skip to content

Style tweaks to OSP LB docs #28141

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.

Sign up for GitHub

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

Merged
maxwelldb merged 1 commit into from
Dec 15, 2020
Merged

Style tweaks to OSP LB docs #28141

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
14 changes: 4 additions & 10 deletions modules/installation-osp-api-octavia.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,18 +1,12 @@
// Module included in the following assemblies:
//
// * networking/openstack/load-balancing-openstack.adoc
// * networking/load-balancing-openstack.adoc

[id="installation-osp-api-octavia_{context}"]
= Scaling clusters for application traffic by using Octavia

{product-title} clusters that run on {rh-openstack-first} can use the Octavia
load balancing service to distribute traffic across multiple VMs or floating IP
addresses. This feature mitigates the bottleneck that single machines or
addresses create.
{product-title} clusters that run on {rh-openstack-first} can use the Octavia load balancing service to distribute traffic across multiple virtual machines (VMs) or floating IP addresses. This feature mitigates the bottleneck that single machines or addresses create.

If your cluster uses Kuryr, the Cluster Network Operator created an internal
Octavia load balancer at deployment. You can use this load balancer for
application network scaling.
If your cluster uses Kuryr, the Cluster Network Operator created an internal Octavia load balancer at deployment. You can use this load balancer for application network scaling.

If your cluster does not use Kuryr, you must create your own Octavia load
balancer to use it for application network scaling.
If your cluster does not use Kuryr, you must create your own Octavia load balancer to use it for application network scaling.
10 changes: 5 additions & 5 deletions modules/installation-osp-api-scaling.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * networking/openstack/load-balancing-openstack.adoc
// * networking/load-balancing-openstack.adoc

[id="installation-osp-api-scaling_{context}"]
= Scaling clusters by using Octavia
Expand All @@ -9,11 +9,11 @@ If you want to use multiple API load balancers, or if your cluster does not use

.Prerequisites

* Octavia is available on your {rh-openstack} deployment.
* Octavia is available on your {rh-openstack-first} deployment.

.Procedure

. From a command line, create an Octavia load balancer that uses the Amphora driver:
. From a command line, create an Octavia load balancer that uses the Amphora driver:
+
[source,terminal]
----
Expand All @@ -31,7 +31,7 @@ $ openstack loadbalancer listener create --name API_OCP_CLUSTER_6443 --protocol
+
[NOTE]
====
To view the load balancer's status, enter `openstack loadbalancer list`.
To view the status of the load balancer, enter `openstack loadbalancer list`.
====

. Create a pool that uses the round robin algorithm and has session persistence enabled:
Expand Down Expand Up @@ -76,7 +76,7 @@ Your cluster now uses Octavia for load balancing.

[NOTE]
====
If Kuryr uses the Octavia Amphora driver, all traffic is routed through a single Amphora VM.
If Kuryr uses the Octavia Amphora driver, all traffic is routed through a single Amphora virtual machine (VM).

You can repeat this procedure to create additional load balancers, which can alleviate the bottleneck.
====
9 changes: 4 additions & 5 deletions modules/installation-osp-kuryr-api-scaling.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,18 +1,17 @@
// Module included in the following assemblies:
//
// * networking/openstack/load-balancing-openstack.adoc
// * networking/load-balancing-openstack.adoc

[id="installation-osp-kuryr-api-scaling_{context}"]
= Scaling clusters that use Kuryr by using Octavia

If your cluster uses Kuryr, associate your cluster's API floating IP address
with the pre-existing Octavia load balancer.
If your cluster uses Kuryr, associate the API floating IP address of your cluster with the pre-existing Octavia load balancer.

.Prerequisites

* Your {product-title} cluster uses Kuryr.

* Octavia is available on your {rh-openstack} deployment.
* Octavia is available on your {rh-openstack-first} deployment.

.Procedure

Expand All @@ -34,7 +33,7 @@ Your cluster now uses Octavia for load balancing.

[NOTE]
====
If Kuryr uses the Octavia Amphora driver, all traffic is routed through a single Amphora VM.
If Kuryr uses the Octavia Amphora driver, all traffic is routed through a single Amphora virtual machine (VM).

You can repeat this procedure to create additional load balancers, which can alleviate the bottleneck.
====
10 changes: 5 additions & 5 deletions modules/installation-osp-kuryr-ingress-scaling.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * networking/openstack/load-balancing-openstack.adoc
// * networking/load-balancing-openstack.adoc

[id="installation-osp-kuryr-octavia-scale_{context}"]
= Scaling for ingress traffic by using {rh-openstack} Octavia
Expand Down Expand Up @@ -69,8 +69,8 @@ You can delete timestamps and other information that is irrelevant to load balan
$ oc apply -f external_router.yaml
----

. Verify that the service's external IP address is the same as the one that is associated with the load balancer:
.. On a command line, retrieve the service's external IP address:
. Verify that the external IP address of the service is the same as the one that is associated with the load balancer:
.. On a command line, retrieve the external IP address of the service:
+
[source,terminal]
----
Expand All @@ -85,7 +85,7 @@ router-external-default LoadBalancer 172.30.235.33 10.46.22.161 80:3011
router-internal-default ClusterIP 172.30.115.123 <none> 80/TCP,443/TCP,1936/TCP 22h
----

.. Retrieve the load balancer's IP address:
.. Retrieve the IP address of the load balancer:
+
[source,terminal]
----
Expand Down Expand Up @@ -116,7 +116,7 @@ You can now use the value of `EXTERNAL-IP` as the new Ingress address.

[NOTE]
====
If Kuryr uses the Octavia Amphora driver, all traffic is routed through a single Amphora VM.
If Kuryr uses the Octavia Amphora driver, all traffic is routed through a single Amphora virtual machine (VM).

You can repeat this procedure to create additional load balancers, which can alleviate the bottleneck.
====
2 changes: 1 addition & 1 deletion modules/installation-osp-kuryr-octavia-upgrade.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * networking/openstack/load-balancing-openstack.adoc
// * networking/load-balancing-openstack.adoc

[id="installation-osp-kuryr-octavia-configure_{context}"]
= Using the Octavia OVN load balancer provider driver with Kuryr SDN
Expand Down