shiftstack edits

_topic_map.yml

@@ -136,8 +136,8 @@ Topics:
 - Name: Installing on OpenStack
   Dir: installing_openstack
   Topics:
-  - Name: Installing a cluster on OpenStack
-    File: installing-openstack-installer
+#  - Name: Installing a cluster on OpenStack
+#    File: installing-openstack-installer
   - Name: Installing a cluster on OpenStack with customizations
     File: installing-openstack-installer-custom
   - Name: Installing a cluster on OpenStack with Kuryr

installing/installing_openstack/installing-openstack-installer-custom.adoc

@@ -25,7 +25,7 @@ include::modules/installation-osp-describing-cloud-parameters.adoc[leveloffset=+
 include::modules/installation-obtaining-installer.adoc[leveloffset=+1]
 include::modules/installation-initializing.adoc[leveloffset=+1]
 include::modules/installation-configuration-parameters.adoc[leveloffset=+1]
-include::modules/installation-osp-installation-parameters.adoc[leveloffset=+2]
+include::modules/installation-osp-config-yaml.adoc[leveloffset=+2]
 include::modules/ssh-agent-using.adoc[leveloffset=+1]
 include::modules/installation-osp-accessing-api.adoc[leveloffset=+1]
 include::modules/installation-osp-accessing-api-floating.adoc[leveloffset=+2]
@@ -39,4 +39,4 @@ include::modules/installation-osp-configuring-floating-ip.adoc[leveloffset=+1]
 
 * xref:../../installing/install_config/customizations.adoc#customizations[Customize your cluster].
 * If necessary, you can
-xref:../../telemetry/opting-out-of-telemetry.adoc#opting-out-of-telemetry[opt out of telemetry].
+xref:../../telemetry/opting-out-of-telemetry.adoc#opting-out-of-telemetry[opt out of telemetry].

installing/installing_openstack/installing-openstack-installer-kuryr.adoc

@@ -25,8 +25,8 @@ include::modules/installation-osp-describing-cloud-parameters.adoc[leveloffset=+
 include::modules/installation-obtaining-installer.adoc[leveloffset=+1]
 include::modules/installation-initializing.adoc[leveloffset=+1]
 include::modules/installation-configuration-parameters.adoc[leveloffset=+1]
-include::modules/installation-osp-installation-parameters.adoc[leveloffset=+2]
-include::modules/installation-osp-about-kuryr.adoc[leveloffset=+2]
+include::modules/installation-osp-config-yaml.adoc[leveloffset=+2]
+include::modules/installation-osp-about-kuryr.adoc[leveloffset=+1]
 include::modules/installation-osp-enabling-kuryr.adoc[leveloffset=+2]
 include::modules/ssh-agent-using.adoc[leveloffset=+1]
 include::modules/installation-osp-accessing-api.adoc[leveloffset=+1]
@@ -41,4 +41,4 @@ include::modules/installation-osp-configuring-floating-ip.adoc[leveloffset=+1]
 
 * xref:../../installing/install_config/customizations.adoc#customizations[Customize your cluster].
 * If necessary, you can
-xref:../../telemetry/opting-out-of-telemetry.adoc#opting-out-of-telemetry[opt out of telemetry].
+xref:../../telemetry/opting-out-of-telemetry.adoc#opting-out-of-telemetry[opt out of telemetry].

installing/installing_openstack/installing-openstack-troubleshooting.adoc

@@ -30,16 +30,16 @@ The console logs appear.
 .Procedure
 
 . Get the IP address of the node on the private network:
-[source,sh]
++
 ----
 $ openstack server list | grep master
 | 0dcd756b-ad80-42f1-987a-1451b1ae95ba | cluster-wbzrr-master-1     | ACTIVE    | cluster-wbzrr-openshift=172.24.0.21                | rhcos           | m1.s2.xlarge |
 | 3b455e43-729b-4e64-b3bd-1d4da9996f27 | cluster-wbzrr-master-2     | ACTIVE    | cluster-wbzrr-openshift=172.24.0.18                | rhcos           | m1.s2.xlarge |
 | 775898c3-ecc2-41a4-b98b-a4cd5ae56fd0 | cluster-wbzrr-master-0     | ACTIVE    | cluster-wbzrr-openshift=172.24.0.12                | rhcos           | m1.s2.xlarge |
 ----
 
-. Connect to the instancing from the the master that holds the API VIP (and API FIP) as a jumpbox:
-
+. Connect to the instance from the the master that holds the API VIP (and API FIP) as a jumpbox:
++
 ----
 $ ssh -J core@${FIP} core@<host>
 ----

modules/completing-installation.adoc

@@ -5,7 +5,7 @@
 [id="completing-installation_{context}"]
 = Completing and verifying the {product-title} installation
 
-When the bootstrap node is done with its work and has handed off control to the new {product-title} cluster, the bootstrap node is destroyed. The installer waits for the cluster to initialize, creates a route to the {product-title} console, and presents the information and credentials you require to log in to the cluster. Here’s an example:
+When the bootstrap node is done with its work and has handed off control to the new {product-title} cluster, the bootstrap node is destroyed. The installation program waits for the cluster to initialize, creates a route to the {product-title} console, and presents the information and credentials you require to log in to the cluster. Here’s an example:
 
 ----
 INFO Install complete!                                

modules/installation-about-restricted-network.adoc

@@ -8,7 +8,7 @@
 In {product-title} {version}, you can perform an installation that does not
 require an active connection to the internet to obtain software components. You
 complete an installation in a restricted network on only infrastructure that you provision,
-not infrastructure that the installer provisions, so your platform selection is
+not infrastructure that the installation program provisions, so your platform selection is
 limited.
 // maybe point out that you can follow the bare metal installation rules on supported hardware and link to the matrix
 

modules/installation-azure-limits.adoc

@@ -43,17 +43,17 @@ To deploy more worker nodes, enable autoscaling, deploy large workloads, or use
 a different instance type, you must further increase the vCPU limit for your
 account to ensure that your cluster can deploy the machines that you require.
 
-By default, the installer distributes control plane and compute machines across
+By default, the installation program distributes control plane and compute machines across
 link:https://azure.microsoft.com/en-us/global-infrastructure/availability-zones/[all availability zones]
 within
 link:https://azure.microsoft.com/en-us/global-infrastructure/regions[a region].
 To ensure high availability for your cluster, select a region with at least
 three availablity zones. If your region contains fewer than three availability
-zones, the installer places more than one control plane machine in the
+zones, the installation program places more than one control plane machine in the
 available zones.
 ////
 You can [provide an install-config](../overview.md#multiple-invocations) to
-[configure](customization.md) the installer to use specific zones to override the defaults.
+[configure](customization.md) the installation program to use specific zones to override the defaults.
 ////
 
 |VNet

modules/installation-configuration-parameters.adoc

@@ -23,9 +23,11 @@ ifeval::["{context}" == "installing-aws-customizations"]
 :aws:
 endif::[]
 ifeval::["{context}" == "installing-openstack-installer-custom"]
+:osp:
 :osp-custom:
 endif::[]
 ifeval::["{context}" == "installing-openstack-installer-kuryr"]
+:osp:
 :osp-kuryr:
 endif::[]
 
@@ -71,9 +73,9 @@ must match the `controlPlane.platform` parameter value.
 |`metadata.name`
 |The name of your cluster.
 |A string that contains uppercase or lowercase letters, such as `dev`.
-ifdef::osp-custom,osp-kuryr[]
+ifdef::osp[]
 The string must be 14 characters or fewer long.
-endif::osp-custom,osp-kuryr[]
+endif::osp[]
 
 |`platform.<platform>.region`
 |The region to deploy your cluster in.
@@ -212,6 +214,48 @@ in the AWS documentation.
 |====
 endif::aws[]
 
+ifdef::osp[]
+.Additional OpenStack parameters
+[cols=".^2m,.^3a,^3a,options="header"]
+|====
+|Parameter|Description|Values
+
+|`machines.platform.openstack.region`
+|The region where the OpenStack cluster is created.
+|String, for example `region1`.
+
+|`machines.platform.openstack.cloud`
+|The name of the OpenStack cloud to use from the list of clouds in the
+`clouds.yaml` file.
+|String, for example `MyCloud`.
+
+|`machines.platform.openstack.externalNetwork`
+|The OpenStack external network name to be used for installation.
+|String, for example `external`.
+
+|`machines.platform.openstack.computeFlavor`
+|The OpenStack flavor to use for control plane and compute machines.
+|String, for example `m1.xlarge`.
+
+|`machines.platform.openstack.lbFloatingIP`
+|An existing floating IP address to associate with the load balancer API.
+|An IP address, for example `128.0.0.1`.
+
+|`machines.platform.openstack.trunkSupport`
+|Whether OpenStack ports can be trunked.
+|`true` or `false`
+
+|`machines.platform.openstack.octaviaSupport`
+|Whether OpenStack supports Octavia.
+|`true` or `false`
+
+|`machines.platform.openstack.defaultMachinePlatform`
+| _Optional_. The default configuration used when installing on OpenStack for
+machine pools that do not define their own platform configuration.
+| -
+|====
+endif::osp[]
+
 ifdef::azure[]
 .Additional Azure parameters
 [cols=".^2,.^3a,.^3a",options="header"]

modules/installation-gcp-permissions.adoc

@@ -10,7 +10,7 @@ grant that service account all permissions, including those that are required to
 install {product-title}. To deploy an {product-title} cluster, the service
 account requires the following permissions:
 
-.Required roles for the installer
+.Required roles for the installation program
 * Compute Admin
 * DNS Administrator
 * Security Admin

modules/installation-initializing.adoc

@@ -21,7 +21,12 @@ endif::[]
 ifeval::["{context}" == "installing-gcp-customizations"]
 :gcp:
 endif::[]
-
+ifeval::["{context}" == "installing-openstack-installer-custom"]
+:osp:
+endif::[]
+ifeval::["{context}" == "installing-openstack-installer-kuryr"]
+:osp:
+endif::[]
 
 [id="installation-initializing_{context}"]
 = Creating the installation configuration file
@@ -97,6 +102,15 @@ specified by the service account that you configured.
 ... Select the base domain to deploy the cluster to. The base domain corresponds
 to the public DNS zone that you created for your cluster.
 endif::gcp[]
+ifdef::osp[]
+.. Select *openstack* as the platform to target.
+.. Specify the OpenStack external network name to use for installing the cluster.
+.. Specify the Floating IP address to use for external access to the OpenShift API.
+.. Specify the OpenStack flavor with at least 16 GB RAM to use for control plane
+and compute nodes.
+.. Select the base domain to deploy the cluster to. All DNS records will be
+sub-domains of this base and will also include the cluster name.
+endif::osp[]
 ... Enter a descriptive name for your cluster.
 ifdef::gcp[]
 If you provide a name that is longer

modules/installation-launching-installer.adoc

@@ -144,7 +144,6 @@ generated.
 .. Select the base domain to deploy the cluster to. The base domain corresponds
 to the Azure DNS Zone that you created for your cluster.
 endif::azure[]
-.. Enter a descriptive name for your cluster.
 ifdef::gcp[]
 .. Select *gcp* as the platform to target.
 .. If you have not configured the service account key for your GCP account on
@@ -156,6 +155,15 @@ specified by the service account that you configured.
 .. Select the base domain to deploy the cluster to. The base domain corresponds
 to the public DNS zone that you created for your cluster.
 endif::gcp[]
+ifdef::osp[]
+.. Select *openstack* as the platform to target.
+.. Specify the OpenStack external network name to use for installing the cluster.
+.. Specify the Floating IP address to use for external access to the OpenShift API.
+.. Specify the OpenStack flavor with at least 16 GB RAM to use for control plane
+and compute nodes.
+.. Select the base domain to deploy the cluster to. All DNS records will be
+sub-domains of this base and will also include the cluster name.
+endif::osp[]
 .. Enter a descriptive name for your cluster.
 ifdef::gcp[]
 If you provide a name that is longer

modules/installation-osp-about-kuryr.adoc

@@ -5,9 +5,9 @@
 [id="installation-osp-about-kuryr_{context}"]
 = About Kuryr
 
-Kuryr is a container network interface (CNI) plug-in that uses Neutron and Octavia to provide networking to pods and services. It is primarily designed for {product-title} clusters that run on OpenStack VMs.
+Kuryr is a container network interface (CNI) plug-in that uses Neutron and Octavia to provide networking to Pods and Services. It is primarily designed for {product-title} clusters that run on OpenStack VMs.
 
-Kuryr improves network performance by connecting pods to the OpenStack SDN. It also provides connections between pods and OpenStack virtual instances.
+Kuryr improves network performance by connecting Pods to the OpenStack SDN. It also provides connections between Pods and OpenStack virtual instances.
 
 [IMPORTANT]
 ====
@@ -16,19 +16,24 @@ Kuryr is recommended for deployments on encapsulated OpenStack tenant networks t
 The default OpenShift SDN is recommended if:
 
 * You use provider networks or tenant VLANs.
-* The deployment will use many services on a few hypervisors. Each service creates an Octavia Amphora virtual machine in OpenStack that hosts a required load balancer.
-* You need UDP services.
+* The deployment will use many Services on a few hypervisors. Each service creates an Octavia Amphora virtual machine in OpenStack that hosts a required load balancer.
+* You need UDP Services.
 ====
 
-You can enable Kuryr in your project by editing a parameter in `install-config.yaml`.
+You can enable Kuryr in your project by editing a parameter in the `install-config.yaml` file.
 
 To learn more about Kuryr, see https://docs.openstack.org/kuryr-kubernetes/latest/[its documentation].
 
 == Known limitations
 
 When using Kuryr SDN:
 
-* An Amphora load balancer VM is deployed deployed per OpenShift service with the default Octavia load balancer driver (Amphora driver). If the environment is resource-constrained, creating a large number of services can negatively impact performance.
-* Some versions of Octavia do not support UDP listeners. Using these versions of Octavia means that you cannot use OpenShift UDP services.
+* An Amphora load balancer VM is deployed deployed per {product-title} service with the default Octavia load balancer driver, the Amphora driver. If the environment is resource-constrained, creating a large number of Services can negatively impact performance.
++
+[NOTE]
+====
+Remember that the {product-title} cluster itself and its supporting components create Services. For example, Kuryr itself creates around 40 load balancers.
+====
+* Some versions of Octavia do not support UDP listeners. Using these versions of Octavia means that you cannot use {product-title} UDP Services.
 * Octavia does not support UDP and TCP listeners on the same port. If there is a conflict, only the TCP listener is created.
-** Due to this limitation, Kuryr forces pods to use TCP for DNS resolution (`use-vc` option at `resolv.conf`). Pods that run Go applications compiled with the `CGO_DEBUG` flag disabled may fail because the `go` resolver only uses UDP.
+** Due to this limitation, Kuryr forces Pods to use TCP for DNS resolution (`use-vc` option at `resolv.conf`). Pods that run Go applications compiled with the `CGO_DEBUG` flag disabled might fail because the `go` resolver only uses UDP.

modules/installation-osp-accessing-api-floating.adoc

@@ -8,7 +8,7 @@
 
 = Enabling access with floating IP addresses
 
-Make {product-title} API endpoints accessible by attaching two floating IP (FIP) addresses to them: one for the API load balancer (`lb FIP`), and one for OpenShift applications (`apps FIP`).
+Make {product-title} API endpoints accessible by attaching two floating IP (FIP) addresses to them: one for the API load balancer (`lb FIP`), and one for {product-title} applications (`apps FIP`).
 
 [IMPORTANT]
 The load balancer FIP is also used in the `install-config.yaml` file.
@@ -30,5 +30,5 @@ api.<cluster name>.<base domain>  IN  A  <lb FIP>
 +
 [NOTE]
 ====
-If you don't control the DNS server, you can add the record to your `/etc/hosts` file instead. This action makes the API accessible to you only, which is not suitable for production deployment, but does allow installation for development and testing.
-====
+If you do not control the DNS server you can add the record to your `/etc/hosts` file instead. This action makes the API accessible to you only, which is not suitable for production deployment but does allow installation for development and testing.
+====

modules/installation-osp-accessing-api-no-floating.adoc

@@ -8,6 +8,6 @@
 
 = Enabling access without floating IP addresses
 
-If you can't use floating IP addresses, the {product-title} installation may still complete. However, the installer will fail after it times out waiting for API access.
+If you cannot use floating IP addresses, the {product-title} installation might still finish. However, the installation program fails after it times out waiting for API access.
 
-After the installer times out, the cluster may still stand up. After the bootstrapping processing begins, it should complete. You must edit the cluster's networking configuration after it is deployed, however.
+After the installation program times out, the cluster might still initialize. After the bootstrapping processing begins, it must complete. You must edit the cluster's networking configuration after it is deployed, however.

modules/installation-osp-balancing-external-loads.adoc

@@ -7,7 +7,7 @@
 
 Configure an external load balancer in OpenStack to resolve external networking needs.
 
-The load balancer serves ports 6443, 443, and 80 to any users of the system. Port 22623 serves Ignition start-up configurations to the {product-title} machines, and should not be reachable from outside the cluster.
+The load balancer serves ports 6443, 443, and 80 to any users of the system. Port 22623 serves Ignition start-up configurations to the {product-title} machines and must not be reachable from outside the cluster.
 
 .Prerequisites
 
@@ -33,7 +33,6 @@ $ openstack server list
 . Incorporate the listed floating IP addresses into the load balancer configuration to allow access the cluster via port 6443.
 +
 .A HAProxy configuration for port 6443
-====
 [source,txt]
 ----
 listen <cluster name>-api-6443
@@ -44,7 +43,6 @@ listen <cluster name>-api-6443
     server <cluster name>-master-0 <floating ip>:6443 check
     server <cluster name>-master-1 <floating ip>:6443 check
 ----
-====
 
 . Repeat the previous three steps for ports 443 and 80.
 
@@ -65,15 +63,17 @@ You can also specify a particular IP address with `/32`.
 ----
 <load balancer ip> api.<cluster-name>.<base domain>
 ----
++
+The external load balancer is now available.
 
-The external load balancer is now available. Verify its functionality by using the following curl command:
-
+. Verify the load balancer's functionality by using the following curl command:
++
 ----
 $ curl https://<loadbalancer-ip>:6443/version --insecure
 ----
-
-The result should resemble:
-====
++
+The output resembles the following example:
++
 [source,json]
 ----
 {
@@ -88,12 +88,12 @@ The result should resemble:
   "platform": "linux/amd64"
 }
 ----
-====
-
-You may verify that the Ignition configurations are only available from within the deployment. If you run a curl command on port 22623 from somewhere external to the deployment:
 
+. Optiona: Verify that the Ignition configuration files are available only from
+within the cluster by running a curl command on port 22623 from outside the cluster:
++
 ----
 $ curl https://<loadbalancer ip>:22623/config/master --insecure
 ----
-
-The command should fail.
++
+The command fails.