openshift · maxwelldb · Jun 24, 2020 · Jun 17, 2020
diff --git a/modules/dynamic-provisioning-available-plugins.adoc b/modules/dynamic-provisioning-available-plugins.adoc
@@ -17,7 +17,7 @@ configured provider's API to create new storage resources:
 |Provisioner plug-in name
 |Notes
 
-|OpenStack Cinder
+|{rh-openstack-first} Cinder
 |`kubernetes.io/cinder`
 |
 

diff --git a/modules/dynamic-provisioning-cinder-definition.adoc b/modules/dynamic-provisioning-cinder-definition.adoc
@@ -3,7 +3,7 @@
 // * storage/dynamic-provisioning.adoc
 
 [id="openstack-cinder-storage-class_{context}"]
-= OpenStack Cinder object definition
+= {rh-openstack} Cinder object definition
 
 .cinder-storageclass.yaml
 [source,yaml]

diff --git a/modules/installation-initializing.adoc b/modules/installation-initializing.adoc
@@ -58,7 +58,7 @@ ifdef::gcp[]
 Google Cloud Platform (GCP).
 endif::gcp[]
 ifdef::osp[]
-OpenStack.
+{rh-openstack-first}.
 endif::osp[]
 
 .Prerequisites

diff --git a/modules/installation-osp-about-kuryr.adoc b/modules/installation-osp-about-kuryr.adoc
@@ -6,16 +6,16 @@
 = About Kuryr SDN
 
 link:https://docs.openstack.org/kuryr-kubernetes/latest/[Kuryr] is a container
-network interface (CNI) plug-in solution that uses
-link:https://docs.openstack.org/neutron/latest/[OpenStack Neutron] and
-link:https://docs.openstack.org/octavia/latest/[OpenStack Octavia] to provide
-networking for Pods and Services.
+network interface (CNI) plug-in solution that uses the
+link:https://docs.openstack.org/neutron/latest/[Neutron] and
+link:https://docs.openstack.org/octavia/latest/[Octavia] {rh-openstack-first} services
+to provide networking for Pods and Services.
 
 Kuryr and {product-title} integration is primarily designed for
-{product-title} clusters running on OpenStack VMs. Kuryr improves the
-network performance by plugging OpenShift Pods into OpenStack SDN.
-In addition, it provides interconnectivity between OpenShift Pods and
-OpenStack virtual instances.
+{product-title} clusters running on {rh-openstack} VMs. Kuryr improves the
+network performance by plugging {product-title} Pods into {rh-openstack} SDN.
+In addition, it provides interconnectivity between Pods and
+{rh-openstack} virtual instances.
 
 Kuryr components are installed as Pods in {product-title} using the
 `openshift-kuryr` namespace:
@@ -33,9 +33,9 @@ used to back {product-title} via Kuryr. This includes open source solutions
 such as Open vSwitch (OVS) and Open Virtual Network (OVN) as well as
 Neutron-compatible commercial SDNs.
 
-Kuryr is recommended for OpenShift deployments on encapsulated OpenStack tenant
+Kuryr is recommended for {product-title} deployments on encapsulated {rh-openstack} tenant
 networks to avoid double encapsulation, such as running an encapsulated
-OpenShift SDN over an OpenStack network.
+{product-title} SDN over an {rh-openstack} network.
 
 Conversely, Kuryr is not recommended in the following cases:
 

diff --git a/modules/installation-osp-config-yaml.adoc b/modules/installation-osp-config-yaml.adoc
@@ -4,7 +4,7 @@
 // * installing/installing_openstack/installing-openstack-installer-kuryr.adoc
 
 [id="installation-osp-config-yaml_{context}"]
-= Sample customized `install-config.yaml` file for OpenStack
+= Sample customized `install-config.yaml` file for {rh-openstack}
 
 This sample `install-config.yaml` demonstrates all of the possible {rh-openstack-first}
 customization options.

diff --git a/modules/installation-osp-creating-image.adoc b/modules/installation-osp-creating-image.adoc
@@ -33,7 +33,7 @@ your {product-title} version if they are available.
 +
 [NOTE]
 ====
-You must decompress the OpenStack image before the cluster can use it.
+You must decompress the {rh-openstack} image before the cluster can use it.
 ====
 
 . From the image that you downloaded, create an image that is named `rhcos` in your cluster by using the {rh-openstack} CLI:

diff --git a/modules/installation-osp-default-deployment.adoc b/modules/installation-osp-default-deployment.adoc
@@ -8,7 +8,7 @@ ifeval::["{context}" == "installing-openstack-installer-custom"]
 endif::[]
 
 [id="installation-osp-default-deployment_{context}"]
-= Resource guidelines for installing {product-title} on OpenStack
+= Resource guidelines for installing {product-title} on {rh-openstack}
 
 Your quota must meet the following requirements to run the {product-title} installation program in {rh-openstack-first}.
 

diff --git a/modules/installation-osp-default-kuryr-deployment.adoc b/modules/installation-osp-default-kuryr-deployment.adoc
@@ -3,7 +3,7 @@
 // * installing/installing_openstack/installing-openstack-installer-kuryr.adoc
 
 [id="installation-osp-default-kuryr-deployment_{context}"]
-= Resource guidelines for installing {product-title} on OpenStack with Kuryr
+= Resource guidelines for installing {product-title} on {rh-openstack} with Kuryr
 
 When using Kuryr SDN, the Pods, Services, namespaces, and network policies are
 using resources from the {rh-openstack} quota; this increases the minimum
@@ -67,7 +67,7 @@ machines, and a bootstrap machine.
 
 To enable Kuryr SDN, your environment must meet the following requirements:
 
-* Run OpenStack 13+.
+* Run {rh-openstack} 13+.
 * Have Overcloud with Octavia.
 * Use Neutron Trunk ports extension.
 * Use `openvswitch` firewall driver if ML2/OVS Neutron driver is used instead

diff --git a/modules/installation-osp-describing-cloud-parameters.adoc b/modules/installation-osp-describing-cloud-parameters.adoc
@@ -13,14 +13,14 @@ The {product-title} installation program relies on a file called `clouds.yaml`.
 
 . Create the `clouds.yaml` file:
 
-** If your OpenStack distribution includes the Horizon web UI, generate a `clouds.yaml` file in it.
+** If your {rh-openstack} distribution includes the Horizon web UI, generate a `clouds.yaml` file in it.
 +
 [IMPORTANT]
 ====
 Remember to add a password to the `auth` field. You can also keep secrets in link:https://docs.openstack.org/os-client-config/latest/user/configuration.html#splitting-secrets[a separate file] from `clouds.yaml`.
 ====
 
-** If your OpenStack distribution does not include the Horizon web UI, or you do not want to use Horizon, create the file yourself. For detailed information about `clouds.yaml`, see https://docs.openstack.org/openstacksdk/latest/user/config/configuration.html#config-files[Config files] in the {rh-openstack} documentation.
+** If your {rh-openstack} distribution does not include the Horizon web UI, or you do not want to use Horizon, create the file yourself. For detailed information about `clouds.yaml`, see https://docs.openstack.org/openstacksdk/latest/user/config/configuration.html#config-files[Config files] in the {rh-openstack} documentation.
 +
 ----
 clouds:

diff --git a/modules/installation-osp-enabling-swift.adoc b/modules/installation-osp-enabling-swift.adoc
@@ -5,9 +5,9 @@
 // * installing/installing_openstack/installing-openstack-installer-kuryr.adoc
 
 [id="installation-osp-enabling-swift_{context}"]
-= Enabling Swift on OpenStack
+= Enabling Swift on {rh-openstack}
 
-{product-title} on {rh-openstack-first} uses https://docs.openstack.org/security-guide/object-storage.html[OpenStack Object Storage (Swift)] to store and serve user configuration files.
+{product-title} on {rh-openstack-first} uses https://docs.openstack.org/security-guide/object-storage.html[{rh-openstack} Object Storage (Swift)] to store and serve user configuration files.
 
 Swift is operated by a user account with the `swiftoperator` role and `temp-url` support.
 

diff --git a/modules/installation-osp-kuryr-config-yaml.adoc b/modules/installation-osp-kuryr-config-yaml.adoc
@@ -3,7 +3,7 @@
 // * installing/installing_openstack/installing-openstack-installer-kuryr.adoc
 
 [id="installation-osp-kuryr-config-yaml_{context}"]
-= Sample customized `install-config.yaml` file for OpenStack with Kuryr
+= Sample customized `install-config.yaml` file for {rh-openstack} with Kuryr
 
 To deploy with Kuryr SDN instead of the default OpenShift SDN, you must
 modify the `install-config.yaml` file to include `Kuryr` as the desired
@@ -61,6 +61,6 @@ sshKey: ssh-ed25519 AAAA...
 Both `trunkSupport` and `octaviaSupport` are automatically discovered by the
 installer, so there is no need to set them. But if your environment does not
 meet both requirements, Kuryr SDN will not properly work. Trunks are needed
-to connect the Pods to the OpenStack network and Octavia is required to create the
+to connect the Pods to the {rh-openstack} network and Octavia is required to create the
 OpenShift Services.
 ====
diff --git a/modules/installation-osp-kuryr-increase-quota.adoc b/modules/installation-osp-kuryr-increase-quota.adoc
@@ -5,7 +5,7 @@
 [id="installation-osp-kuryr-increase-quota_{context}"]
 = Increasing quota
 
-When using Kuryr SDN, you must increase quotas to satisfy the OpenStack
+When using Kuryr SDN, you must increase quotas to satisfy the {rh-openstack-first}
 resources used by Pods, Services, namespaces, and network policies.
 
 .Procedure

diff --git a/modules/installation-osp-kuryr-neutron-configuration.adoc b/modules/installation-osp-kuryr-neutron-configuration.adoc
@@ -6,7 +6,7 @@
 = Configuring Neutron
 
 Kuryr CNI leverages the Neutron Trunks extension to plug containers into the
-OpenStack SDN, so you must use the `trunks` extension for Kuryr to properly work.
+{rh-openstack-first} SDN, so you must use the `trunks` extension for Kuryr to properly work.
 
 In addition, if you leverage the default ML2/OVS Neutron driver, the firewall
 must be set to `openvswitch` instead of `ovs_hybrid` so that security groups are

diff --git a/modules/installation-osp-kuryr-octavia-configuration.adoc b/modules/installation-osp-kuryr-octavia-configuration.adoc
@@ -5,19 +5,19 @@
 [id="installation-osp-kuryr-octavia-configuration_{context}"]
 = Configuring Octavia
 
-Kuryr SDN uses OpenStack Octavia LBaaS to implement OpenShift Services. Thus,
-you must install and configure Octavia components in your OpenStack environment
+Kuryr SDN uses {rh-openstack-first}'s Octavia LBaaS to implement {product-title} Services. Thus,
+you must install and configure Octavia components in {rh-openstack}
 to use Kuryr SDN.
 
 To enable Octavia, you must include the Octavia Service during the installation
-of the OpenStack Overcloud, or upgrade the Octavia Service if the Overcloud
+of the {rh-openstack} Overcloud, or upgrade the Octavia Service if the Overcloud
 already exists. The following steps for enabling Octavia apply to both a clean
 install of the Overcloud or an Overcloud update.
 
 [NOTE]
 ====
 The following steps only capture the key pieces required during the
-https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/director_installation_and_usage/[deployment of OpenStack]
+https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/director_installation_and_usage/[deployment of {rh-openstack}]
 when dealing with Octavia. It is also important to note that
 https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/director_installation_and_usage/configuring-a-container-image-source#registry-methods[registry methods]
 vary.
@@ -87,7 +87,7 @@ parameter_defaults:
 +
 [NOTE]
 ====
-This is not needed for Red Hat OpenStack Platform 14+.
+This is not needed for {rh-openstack} 14+.
 ====
 
 . Install or update your Overcloud environment with Octavia:
@@ -101,7 +101,7 @@ openstack overcloud deploy --templates \
 [NOTE]
 ====
 This command only includes the files associated with Octavia; it varies based on
-your specific installation of OpenStack. See the official OpenStack
+your specific installation of {rh-openstack}. See the {rh-openstack}
 documentation for further information. For more information on customizing your
 Octavia installation, see
 https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html-single/networking_guide/#planning_your_octavia_deployment[installation
@@ -188,7 +188,7 @@ controller-0$ sudo docker restart octavia_worker
 
 [NOTE]
 ====
-Depending on your OpenStack environment, Octavia might not support UDP
+Depending on your {rh-openstack} environment, Octavia might not support UDP
 listeners, which means there is no support for UDP Services if Kuryr SDN is
 used.
 ====
diff --git a/modules/nodes-containers-projected-volumes-about.adoc b/modules/nodes-containers-projected-volumes-about.adoc
@@ -16,7 +16,7 @@ The following general scenarios show how you can use projected volumes.
 
 *ConfigMap, Secrets, Downward API.*::
 Projected volumes allow you to deploy containers with configuration data that includes passwords.
-An application using these resources could be deploying OpenStack on Kubernetes. The configuration data might have to be assembled differently depending on if the services are going to be used for production or for testing. If a pod is labeled with production or testing, the downward API selector `metadata.labels` can be used to produce the correct OpenStack configs.
+An application using these resources could be deploying {rh-openstack-first} on Kubernetes. The configuration data might have to be assembled differently depending on if the services are going to be used for production or for testing. If a pod is labeled with production or testing, the downward API selector `metadata.labels` can be used to produce the correct {rh-openstack} configs.
 
 *ConfigMap + Secrets.*::
 Projected volumes allow you to deploy containers involving configuration data and passwords.

diff --git a/modules/openshift-cluster-maximums-major-releases.adoc b/modules/openshift-cluster-maximums-major-releases.adoc
@@ -5,7 +5,7 @@
 [id="cluster-maximums-major-releases_{context}"]
 = {product-title} Tested cluster maximums for major releases
 
-Tested Cloud Platforms for {product-title} 3.x: Red Hat OpenStack, Amazon Web Services and Microsoft Azure.
+Tested Cloud Platforms for {product-title} 3.x: {rh-openstack-first}, Amazon Web Services and Microsoft Azure.
 Tested Cloud Platforms for {product-title} 4.x: Amazon Web Services, Microsoft Azure and Google Cloud Platform.
 
 [options="header",cols="3*"]

diff --git a/modules/persistent-storage-cinder-creating-pv.adoc b/modules/persistent-storage-cinder-creating-pv.adoc
@@ -30,7 +30,7 @@ spec:
 ----
 <1> The name of the volume that is used by persistent volume claims or pods.
 <2> The amount of storage allocated to this volume.
-<3> Indicates `cinder` for OpenStack Cinder volumes.
+<3> Indicates `cinder` for {rh-openstack-first} Cinder volumes.
 <4> The file system that is created when the volume is mounted for the first time.
 <5> The Cinder volume to use.
 +

diff --git a/modules/persistent-storage-cinder-provisioning.adoc b/modules/persistent-storage-cinder-provisioning.adoc
@@ -9,5 +9,5 @@ Storage must exist in the underlying infrastructure before it can be mounted as
 
 .Prerequisites
 
-* {product-title} configured for OpenStack
+* {product-title} configured for {rh-openstack-first}
 * Cinder volume ID
diff --git a/modules/persistent-storage-manila-install.adoc b/modules/persistent-storage-manila-install.adoc
@@ -5,7 +5,7 @@
 [id="persistent-storage-manila-install_{context}"]
 = Installing the external provisioner
 
-To use OpenStack Manila persistent storage you must install
+To use {rh-openstack-first} Manila persistent storage you must install
 and configure an external provisioner in the {product-title}
 cluster.
 
@@ -78,12 +78,12 @@ metadata:
   name: manila-secret <1>
   namespace: default <2>
 data:
-  os-authURL: <base64 encoded OpenStack Keystone URL>
+  os-authURL: <base64 encoded {rh-openstack} Keystone URL>
   os-userName: <base64 encoded Manila username>
   os-password: <base64 encoded password>
-  os-projectName: <base64 encoded OpenStack project (tenant) name>
-  os-domainName: <base64 encoded OpenStack Manila service domain>
-  os-region: <base64 encoded OpenStack region>
+  os-projectName: <base64 encoded {rh-openstack} project (tenant) name>
+  os-domainName: <base64 encoded {rh-openstack} Manila service domain>
+  os-region: <base64 encoded {rh-openstack} region>
 ----
 <1> The secret name will be referenced by the Manila volume's
 StorageClass.
@@ -118,9 +118,9 @@ in. This field is optional, and defaults to `nova`.
 <4> Backend share used for granting access and creating the
 `PersistentVolumeSource`. Valid options are `nfs` and `cephfs`.
 This field is required.
-<5> Name of the secret object containing OpenStack credentials.
+<5> Name of the secret object containing {rh-openstack} credentials.
 This field is required.
-<6> Namespace of the OpenStack credentials secret object. This field
+<6> Namespace of the {rh-openstack} credentials secret object. This field
 is optional, and defaults to `default`.
 <7> Default NFS client for the share exported. This field is optional,
 and is only used for the `NFS` protocol. Defaults to `0.0.0.0`. 

diff --git a/modules/persistent-storage-manila-usage.adoc b/modules/persistent-storage-manila-usage.adoc
@@ -3,15 +3,15 @@
 // * storage/persistent_storage/persistent-storage-manila.adoc
 
 [id="persistent-storage-manila-usage_{context}"]
-= Provisioning an OpenStack Manila persistent volume
+= Provisioning an {rh-openstack} Manila persistent volume
 
-OpenStack Manila shares are dynamically provisioned as needed. When the
+{rh-openstack-first} Manila shares are dynamically provisioned as needed. When the
 PersistentVolumeClaim is deleted the provisioner will automatically 
-delete and unexport the OpenStack Manila share.
+delete and unexport the {rh-openstack} Manila share.
 
 .Prerequisites
 
-* The OpenStack Manila external provisioner must be installed.
+* The {rh-openstack} Manila external provisioner must be installed.
 
 .Procedure
 

diff --git a/modules/prometheus-database-storage-requirements.adoc b/modules/prometheus-database-storage-requirements.adoc
@@ -57,14 +57,14 @@ per 50 nodes and 1800 pods.
 *Lab environment*
 
 In a previous release, all experiments were performed in an {product-title} on
-OpenStack environment:
+{rh-openstack} environment:
 
 * Infra nodes (VMs) - 40 cores, 157 GB RAM.
 * CNS nodes (VMs) - 16 cores, 62 GB RAM, NVMe drives.
 
 [IMPORTANT]
 ====
-Currently, OpenStack environments are not supported for {product-title} {product-version}.
+Currently, {rh-openstack} environments are not supported for {product-title} {product-version}.
 ====
 
 *Recommendations for {product-title}*

diff --git a/modules/recommended-configurable-storage-technology.adoc b/modules/recommended-configurable-storage-technology.adoc
@@ -143,5 +143,5 @@ with the storage layer.
 * It is highly recommended that you use `etcd` with storage that handles serial
 writes (fsync) quickly, such as NVMe or SSD. Ceph, NFS, and spinning disks are
 not recommended.
-* OpenStack Cinder: OpenStack Cinder tends to be adept in ROX access mode use cases.
+* {rh-openstack-first} Cinder: {rh-openstack} Cinder tends to be adept in ROX access mode use cases.
 * Databases: Databases (RDBMSs, NoSQL DBs, etc.) tend to perform best with dedicated block storage.
diff --git a/modules/registry-configuring-storage-openstack-user-infra.adoc b/modules/registry-configuring-storage-openstack-user-infra.adoc
@@ -3,17 +3,17 @@
 // * registry/configuring-registry-storage-openstack-user-infrastructure.adoc
 
 [id="registry-configuring-storage-openstack-user-infra_{context}"]
-= Registry storage for OpenStack with user-provisioned infrastructure
+= Registry storage for {rh-openstack} with user-provisioned infrastructure
 
 You must set up the storage medium manually and configure the settings in the
 registry CRD.
 
 .Prerequisites
 
-* A cluster on OpenStack with user-provisioned infrastructure.
-* To configure registry storage for OpenStack, you need to provide Registry Operator
+* A cluster on {rh-openstack-first} with user-provisioned infrastructure.
+* To configure registry storage for {rh-openstack}, you need to provide Registry Operator
 cloud credentials.
-* For Swift on OpenStack storage the secret is expected to contain the following two keys:
+* For Swift on {rh-openstack} storage the secret is expected to contain the following two keys:
 
 ** `REGISTRY_STORAGE_SWIFT_USER`
 ** `REGISTRY_STORAGE_SWIFT_PASSWORD`
diff --git a/modules/registry-operator-config-resources-secret-openstack.adoc b/modules/registry-operator-config-resources-secret-openstack.adoc
@@ -14,7 +14,7 @@ The `image-registry-private-configuration-user` secret provides
 credentials needed for storage access and management. It overrides the default
 credentials used by the Operator, if default credentials were found.
 
-For Swift on OpenStack storage, the secret is expected to contain the following two keys:
+For Swift on {rh-openstack-first} storage, the secret is expected to contain the following two keys:
 
 * `REGISTRY_STORAGE_SWIFT_USER`
 * `REGISTRY_STORAGE_SWIFT_PASSWORD`

diff --git a/modules/registry-operator-configuration-resource-overview-openstack-swift.adoc b/modules/registry-operator-configuration-resource-overview-openstack-swift.adoc
@@ -3,9 +3,9 @@
 // * registry/configuring_registry_storage/configuring-registry-storage-openstack-user-infrastructure.adoc
 
 [id="registry-operator-configuration-resource-overview-openstack-swift_{context}"]
-= Image Registry Operator configuration parameters for OpenStack Swift
+= Image Registry Operator configuration parameters for {rh-openstack} Swift
 
-The following configuration parameters are available for OpenStack Swift
+The following configuration parameters are available for {rh-openstack-first} Swift
 registry storage.
 
 [cols="3a,8a",options="header"]

diff --git a/welcome/index.adoc b/welcome/index.adoc
@@ -37,8 +37,8 @@ xref:../installing/installing_azure/installing-azure-network-customizations.adoc
 
 - **xref:../installing/installing_bare_metal/installing-bare-metal.adoc#installing-bare-metal[Install a cluster on bare metal]**: If none of the available platform and cloud providers meet your needs, you can install {product-title} on bare metal.
 
-- **Install a cluster on OpenStack Platform**: You can install a cluster on
-xref:../installing/installing_openstack/installing-openstack-installer-custom.adoc#installing-openstack-installer-custom[OpenStack with customizations].
+- **Install a cluster on {rh-openstack-first}**: You can install a cluster on
+xref:../installing/installing_openstack/installing-openstack-installer-custom.adoc#installing-openstack-installer-custom[{rh-openstack} with customizations].
 
 ////
 You can configure an external load balancer for
-Original file line number
+Diff line change
@@ Expand Up / @@ -33,7 +33,7 @@ your {product-title} version if they are available. @@
     +
     [NOTE]
     ====
-    You must decompress the OpenStack image before the cluster can use it.
+    You must decompress the {rh-openstack} image before the cluster can use it.
     ====
     . From the image that you downloaded, create an image that is named `rhcos` in your cluster by using the {rh-openstack} CLI:
@@ Expand Down @@