OSSM-9004 Typos, style things

Author: gwynnemonahan

modules/ossm-about-multi-cluster-mesh-topologies.adoc

@@ -4,13 +4,13 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="ossm-about-multi-cluster-mesh-topologies_{context}"]
-= About multi-cluster mesh topologies 
+= About multi-cluster mesh topologies
 
 In a multi-cluster mesh topology, you install and manage a single {istio} mesh across multiple {ocp-product-title} clusters, enabling communication and service discovery between the services. Two factors determine the multi-cluster mesh topology: control plane topology and network topology. There are two options for each topology. Therefore, there are four possible multi-cluster mesh topology configurations.
 
-* Multi-Primary Single Network: Combines the multi-primary control plane topology and the single network network topology models. 
+* Multi-Primary Single Network: Combines the multi-primary control plane topology and the single network network topology models.
 
-* Multi-Primary Multi-Network: Combines the Combines the multi-primary control plane topology and the multi-network network topology models. 
+* Multi-Primary Multi-Network: Combines the multi-primary control plane topology and the multi-network network topology models.
 
 * Primary-Remote Single Network: Combines the primary-remote control plane topology and the single network network topology models.
 
@@ -23,7 +23,7 @@ A multi-cluster mesh must use one of the following control plane topologies:
 
 * Multi-Primary: In this configuration, a control plane resides on every cluster. Each control plane observes the API servers in all of the other clusters for services and endpoints.
 
-* Primary-Remote: In this configuration, the control plane resides only on one cluster, called the primary cluster. No control plane runs on any of the other clusters, called remote clusters. The control plane on the primary cluster discovers services and endpoints and configures the sidecar proxies for the workloads in all clusters. 
+* Primary-Remote: In this configuration, the control plane resides only on one cluster, called the primary cluster. No control plane runs on any of the other clusters, called remote clusters. The control plane on the primary cluster discovers services and endpoints and configures the sidecar proxies for the workloads in all clusters.
 
 [id="ossm-network-topology-models_{context}"]
 == Network topology models

modules/ossm-accessing-bookinfo-application-using-gateway-api.adoc

@@ -10,7 +10,7 @@ The {k8s} Gateway API deploys a gateway by creating a `Gateway` resource. In {oc
 Red{nbsp}Hat provides support for using the {k8s} Gateway API with {SMProductName}. Red{nbsp}Hat does not provide support for the {k8s} Gateway API custom resource definitions (CRDs). In this procedure, the use of community Gateway API CRDs is shown for demonstration purposes only.
 ====
 
-. Prerequisites
+.Prerequisites
 
 * You are logged in to the {ocp-product-title} web console as `cluster-admin`.
 

modules/ossm-attach-workloads-to-control-plane-revisionbased.adoc

@@ -6,4 +6,4 @@
 = Attach workloads to the control plane by using RevisionBased strategy
 :context: ossm-attach-workloads-to-control-plane-revisionbased
 
-To attach the workloads to a control plane deployed by using the `RevisionBased` strategy, you must set the `istio.io/rev namespace` label to the name of the `IstioRevision`. Alternatively, you can apply the label to the workload pods.
+To attach the workloads to a control plane deployed by using the `RevisionBased` strategy, you must set the `istio.io/rev namespace` label to the name of the `IstioRevision` resource. Alternatively, you can apply the label to the workload pods.

modules/ossm-migrating-read-me-introducing-canary-updates.adoc

@@ -2,16 +2,13 @@
 //
 // * service-mesh-docs-main/about/ossm-migrating-assembly.adoc
 
-//Start of an overall Migrating section.
-//Section is most likely to be reworked/restructured with OSSM 2 to OSSM 3 migration guides for GA. Unknown how many migration guides there are at this time (11/11/2024). It would be beneficial to be able to link from differences to the relevent migration guide so that users A) understand the change, esp significant changes like new operator, installing tracing and Kiali separately, gateways, etc.
-
 :_mod-docs-content-type: CONCEPT
 [id="ossm-migrating-read-me-introducing-canary-updatess_{context}"]
 = Introducing canary updates
 
 {SMProductName} 2 supported only in-place style updates, which created risk for large meshes where, after the control plane was updated, all workloads must update to the new control plane version without a simple way to roll back if something goes wrong.
 
-{SMProduct} 3 retains support for simple in-place style updates, and adds support for canary-style updatess of the Istio control plane using Istio's revision feature.
+{SMProduct} 3 retains support for simple in-place style updates, and adds support for canary-style updates of the Istio control plane using Istio's revision feature.
 
 The `Istio` resource manages Istio revision labels using the `IstioRevision` resource. When the `Istio` resource's `updateStrategy` type is set to `RevisionBased`, it creates Istio revision labels using the `Istio` resource's name combined with the Istio version, for example `mymesh-v1-21-2`.
 

modules/ossm-performing-inplace-update.adoc

@@ -10,7 +10,7 @@ When updating {istio} using the `InPlace` strategy, you can only increment by on
 
 .Prerequisites
 
-* You are logged in to {ocp-product-title} as `cluster-admin`.
+* You are logged in to {ocp-product-title} as a user with the `cluster-admin` role.
 * You have installed the {SMProductName} Operator, and deployed {istio}.
 
 .Procedure
@@ -39,5 +39,5 @@ $ oc get istio <control-plane-name>
 +
 [source,terminal]
 ----
-$ oc rollout restart deployment <deployment-name>
+$ oc rollout restart deployment <deployment_name>
 ----

modules/ossm-performing-revisionbased-update.adoc

@@ -40,5 +40,5 @@ $ oc get istiorevisions
 +
 [source,terminal]
 ----
-$ oc rollout restart deployment <deployment-name>
+$ oc rollout restart deployment <deployment_name>
 ----

modules/ossm-select-revisionbased-strategy.adoc

@@ -8,7 +8,7 @@
 
 To deploy {istio} with the `RevisionBased` strategy, create the {istio} resource with the following `spec.updateStrategy` value:
 
-.Example specification to select RevisionBased strategy
+.Example specification to select `RevisionBased` strategy
 [source,yaml, subs="attributes,verbatim"]
 ----
 kind: Istio
@@ -18,4 +18,4 @@ spec:
     type: RevisionBased
 ----
 
-After you select the strategy for the {istio} resource, the Operator creates a new `IstioRevision` resource with the name <istio resource name>-<version>.
+After you select the strategy for the {istio} resource, the Operator creates a new `IstioRevision` resource with the name `<istio_resource_name>-<version>`.