docs: apply style guide fixes RHOSO

content/patterns/rhoso-gitops/_index.adoc

@@ -2,7 +2,7 @@
 title: RHOSO GitOps
 date: 2026-06-15
 tier: sandbox
-summary: Deploy Red Hat OpenStack Services on OpenShift using GitOps via the rhoso-gitops meta-chart.
+summary: Deploy Red Hat OpenStack Services on OpenShift using GitOps through the rhoso-gitops meta-chart.
 rh_products:
   - Red Hat OpenShift Container Platform
   - Red Hat OpenShift GitOps

content/patterns/rhoso-gitops/cluster-sizing.adoc

@@ -15,15 +15,16 @@ include::modules/cluster-sizing-template.adoc[]
 [id="rhoso-gitops-dataplane-hosts"]
 == Data plane host requirements
 
-The hub cluster sizing tables above cover the {rh-ocp} nodes that host the
-{rh-rhoso-short} control plane. A full {rh-rhoso-short} deployment also
+The preceding hub cluster sizing tables cover the {rh-ocp} nodes that host the
+{rh-rhoso-short} control plane.
+A full {rh-rhoso-short} deployment also
 requires separate {rhel-short} hosts for the data plane (compute nodes running
-dataplane elements).
+data plane elements).
 
 Plan additional {rhel-short} capacity beyond the OpenShift worker sizing in
-`pattern-metadata.yaml`. Operator stages, sync order, and version pins are
-documented in the pattern repository
-link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/blob/main/VERSIONS.md[VERSIONS.md]
+`pattern-metadata.yaml`.
+For Operator stages, sync order, and version pins, see
+the pattern repository link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/blob/main/VERSIONS.md[VERSIONS.md]
 file.
 
 [id="next-steps_rhoso-gitops-cluster-sizing"]

content/patterns/rhoso-gitops/configuration.adoc

@@ -15,4 +15,4 @@ include::modules/rhoso-gitops/rhoso-gitops-configuration.adoc[leveloffset=+1]
 == Next steps
 
 * link:../getting-started/[Deploy the pattern]
-* link:../troubleshooting/[Troubleshooting]
+* link:../troubleshooting/[Troubleshoot the pattern]

content/patterns/rhoso-gitops/getting-started.adoc

@@ -16,4 +16,4 @@ include::modules/rhoso-gitops/rhoso-gitops-deploying.adoc[leveloffset=+1]
 
 * link:../configuration/[Configure the pattern]
 * link:../cluster-sizing/[Review cluster sizing]
-* link:../troubleshooting/[Troubleshooting]
+* link:../troubleshooting/[Troubleshoot the pattern]

content/patterns/rhoso-gitops/troubleshooting.adoc

@@ -12,34 +12,59 @@ include::modules/comm-attributes.adoc[]
 [id="troubleshooting-rhoso-gitops"]
 = Troubleshooting the {rhoso-gitops-pattern}
 
+Use these procedures to validate the pattern, inspect Argo CD application and
+pod status, and review known issues for the {rhoso-gitops-pattern}.
+
 [id="rhoso-gitops-validate-pattern"]
 == Validating the pattern
 
-Run pattern validation commands from the pattern repository root:
+Run the following pattern validation commands from the pattern repository root:
 
+. Validate prerequisites:
++
 [source,terminal]
 ----
 $ ./pattern.sh make validate-prereq
+----
+
+. Validate the schema:
++
+[source,terminal]
+----
 $ ./pattern.sh make validate-schema
+----
+
+. Check Argo CD health:
++
+[source,terminal]
+----
 $ ./pattern.sh make argo-healthcheck
 ----
 
 [id="rhoso-gitops-check-argocd"]
 == Checking Argo CD application status
 
-The pattern uses two Argo CD namespaces. List applications in each:
+The pattern uses two Argo CD namespaces. List applications in each namespace:
 
+. List applications in `vp-gitops`:
++
 [source,terminal]
 ----
 $ oc get applications -n vp-gitops
-$ oc get applications -n openshift-gitops
 ----
 
-Inspect a child application that is out of sync or unhealthy:
+. List applications in `openshift-gitops`:
++
+[source,terminal]
+----
+$ oc get applications -n openshift-gitops
+----
 
+. Inspect a child application that is out of sync or unhealthy:
++
 [source,terminal]
 ----
-$ oc describe application <application-name> -n openshift-gitops
+$ oc describe application <application_name> -n openshift-gitops
 ----
 
 Use the Argo CD UI in the `openshift-gitops` namespace to review sync waves,
@@ -60,29 +85,31 @@ Review logs for a specific pod:
 
 [source,terminal]
 ----
-$ oc logs -n <namespace> <pod-name>
+$ oc logs -n <namespace> <pod_name>
 ----
 
 [id="rhoso-gitops-known-issues"]
 == Known issues
 
-* *`openstack-secrets` disabled* — The default pattern leaves
-  `openstack-secrets` disabled because no Git path is configured (`path: TODO`).
+The following known issues can affect pattern deployment:
+
+* *`openstack-secrets` disabled*: The default pattern leaves
+  `openstack-secrets` disabled because no Git path exists (`path: TODO`).
   Enable it only after you configure secret wiring and a bootstrap credential
   out of band. See link:../configuration/#rhoso-gitops-secret-zero[Secret zero
   (bootstrap credential)].
-* *Upstream sync failures* — Confirm `targetRevision` and paths in
+* *Upstream sync failures*: Confirm that `targetRevision` and paths in
   `overrides/values-rhoso-gitops.yaml` match a tag or branch that exists in
   link:https://github.com/openstack-k8s-operators/gitops[openstack-k8s-operators/gitops].
-* *Operator install delays* — Infrastructure operators in `operator-dependencies`
-  subscribe from the cluster catalog; allow time for OLM to resolve CSVs before
-  later sync waves run.
+* *Operator install delays*: Infrastructure Operators in `operator-dependencies`
+  subscribe from the cluster catalog; allow time for OLM to resolve
+  `ClusterServiceVersions` (CSVs) before later sync waves run.
 
 For community support, open an issue in the
 link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/issues[pattern repository].
 
 [id="next-steps_rhoso-gitops-troubleshooting"]
 == Next steps
 
-* link:../getting-started/[Getting started]
-* link:../configuration/[Configuration]
+* link:../getting-started/[Deploy the pattern]
+* link:../configuration/[Configure the pattern]

modules/rhoso-gitops/rhoso-gitops-about.adoc

@@ -4,22 +4,19 @@
 [id="about-rhoso-gitops-pattern"]
 = About the {rhoso-gitops-pattern}
 
-Deploying {rh-rhoso} spans operators, networking, and control-plane and data-plane
-resources. Teams that rely on imperative scripts or manual cluster changes face
-slow rollouts, configuration drift, and weak audit trails when the stack must be
-upgraded or reproduced.
+Deploying {rh-rhoso} spans Operators, networking, and control-plane and data-plane resources.
+Teams that rely on imperative scripts or manual cluster changes face
+slow rollouts, configuration drift, and weak audit trails when you upgrade or
+reproduce the stack.
 
-The {rhoso-gitops-pattern} addresses that by driving {rh-rhoso-short} from public
-Git through Argo CD: manifests stay declarative and version-controlled, and the
-cluster is reconciled to match what is declared in the repository.
+The {rhoso-gitops-pattern} addresses that by driving {rh-rhoso-short} from public Git through Argo CD: manifests stay declarative and version-controlled, and Argo CD reconciles the cluster to match what the repository declares.
 
 [id="rhoso-gitops-pattern-goals"]
 == Pattern goals
 
 The {rhoso-gitops-pattern} aims to:
 
-* Install the *rhoso-gitops* meta-chart through the Validated Patterns
-  clustergroup and {gitops-title} operator
+* Install the *rhoso-gitops* meta-chart through the {solution-name-upstream} clustergroup and {gitops-title} Operator
 * Create child Argo CD Applications that sync {rh-rhoso-short} stages from upstream
   link:https://github.com/openstack-k8s-operators/gitops[openstack-k8s-operators/gitops]
   (`example/*` Kustomize overlays)
@@ -29,18 +26,20 @@ The {rhoso-gitops-pattern} aims to:
 [id="rhoso-gitops-red-hat-technologies"]
 == Red Hat technologies
 
+The {rhoso-gitops-pattern} uses the following Red Hat products:
+
 * {rh-ocp}
 * {gitops-title}
 * {rh-rhoso}
 
 [id="rhoso-gitops-cluster-scope"]
 == Cluster scope
 
-Validated Patterns distinguish between the *initial cluster* (where the pattern
-is installed) and *managed clusters* (additional {rh-ocp} clusters or hosts
-managed from that hub, for example through {rh-rhacm}).
+{solution-name-upstream} distinguishes between the *initial cluster* (where you
+install the pattern) and *managed clusters* (additional {rh-ocp} clusters or
+hosts managed from that hub, for example through {rh-rhacm}).
 
-The {rhoso-gitops-pattern} is *single-cluster only*. It does not provide
+The {rhoso-gitops-pattern} is *single-cluster only*. It does not include
 multi-cluster support, spoke provisioning, or hub-to-spoke {gitops-shortname}
 fan-out.
 
@@ -51,14 +50,15 @@ fan-out.
 
 | Initial cluster
 | Yes
-| Validated Patterns clustergroup (`values-standalone.yaml`), *rhoso-gitops*
-  meta-chart, and child {rh-rhoso-short} Applications in `openshift-gitops`
+| {solution-name-upstream} clustergroup (`values-standalone.yaml`),
+  *rhoso-gitops* meta-chart, and child {rh-rhoso-short} Applications in
+  `openshift-gitops`
 
 | Managed clusters
 | None
-| Not in scope (`spoke_support: false` in `pattern-metadata.yaml`). No spoke
-  sizing, policies, {rh-rhacm} placement, or remote Argo CD instances are
-  defined or deployed
+| Not in scope (`spoke_support: false` in `pattern-metadata.yaml`). The pattern
+  does not define or deploy spoke sizing, policies, {rh-rhacm} placement, or
+  remote Argo CD instances
 |===
 
 Sizing guidance under `requirements.hub` in the pattern repository applies to
@@ -68,7 +68,7 @@ consistency across spokes) do not apply to this pattern.
 [id="rhoso-gitops-support"]
 == Support
 
-This is a *sandbox tier* Validated Pattern. Support is provided by the community
-on a best-effort basis. For details, see the
+This is a *sandbox tier* pattern. The community provides support on a
+best-effort basis. For details, see the
 link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/blob/main/SUPPORT.md[support policy]
 in the pattern repository.

modules/rhoso-gitops/rhoso-gitops-architecture.adoc

@@ -4,56 +4,65 @@
 [id="rhoso-gitops-architecture"]
 = {rhoso-gitops-pattern} architecture
 
+The {rhoso-gitops-pattern} delivers {rh-rhoso-short} configuration through Argo CD
+Applications that the *rhoso-gitops* meta-chart creates. Use this overview to
+understand GitOps delivery, the dual Argo CD namespaces, infrastructure topology,
+and sync-wave order before you deploy or customize the pattern.
+
 [id="rhoso-gitops-gitops-delivery"]
 == GitOps delivery flow
 
-The pattern uses the Validated Patterns framework to install the *rhoso-gitops*
-Helm meta-chart. That chart creates Argo CD `Application` resources that sync
-{rh-rhoso-short} stages from the upstream
+The pattern uses the {solution-name-upstream} framework to install the
+*rhoso-gitops* Helm meta-chart. That chart creates Argo CD `Application`
+resources that sync {rh-rhoso-short} stages from the upstream
 link:https://github.com/openstack-k8s-operators/gitops[openstack-k8s-operators/gitops]
 repository (`example/*` Kustomize overlays).
 
 The delivery path is:
 
-. Validated Patterns operator reconciles the pattern clustergroup
-. Parent *rhoso-gitops* Application runs in `vp-gitops` (Validated Patterns GitOps)
-. Meta-chart renders child Applications in `openshift-gitops` ({gitops-title})
-. Child apps sync upstream `example/*` overlays in order (operators, networks,
-  control plane, dataplane)
+. The {validated-patterns-op} reconciles the pattern clustergroup
+. The parent *rhoso-gitops* Application runs in `vp-gitops`
+  ({solution-name-upstream} GitOps)
+. The meta-chart renders child Applications in `openshift-gitops`
+  ({gitops-title})
+. The child apps sync upstream `example/*` overlays in order (Operators,
+  networks, control plane, data plane)
 
 .GitOps application delivery and sync-wave ordering
 image::rhoso-gitops/rhoso-gitops-applications.svg[{rhoso-gitops-pattern} GitOps application delivery,700]
 
 The diagram shows the parent Application in `vp-gitops`, child Applications in
 `openshift-gitops`, and the upstream Kustomize overlays they sync. Sync-wave
-annotations order deployment from infrastructure operators through the data
+annotations order deployment from infrastructure Operators through the data
 plane.
 
 [id="rhoso-gitops-dual-argocd"]
 == Dual Argo CD namespaces
 
-* The pattern operator deploys the parent *rhoso-gitops* Application into
-  *`vp-gitops`* (Validated Patterns GitOps).
-* Child {rh-rhoso-short} Applications are created in *`openshift-gitops`*
-  ({gitops-title} operator), per the meta-chart defaults.
+The pattern uses two Argo CD namespaces:
+
+* The {validated-patterns-op} deploys the parent *rhoso-gitops* Application into
+  *`vp-gitops`* ({solution-name-upstream} GitOps).
+* The meta-chart creates child {rh-rhoso-short} Applications in
+  *`openshift-gitops`* ({gitops-title} Operator), per the chart defaults.
 
 [id="rhoso-gitops-infrastructure-topology"]
 == Infrastructure topology
 
-An {rh-ocp} cluster hosts the {rh-rhoso-short} control plane (OpenStack operators
+An {rh-ocp} cluster hosts the {rh-rhoso-short} control plane (OpenStack Operators
 and `OpenStackControlPlane` services on control-plane nodes). Separate {rhel-short}
-hosts run the {rh-rhoso-short} data plane (dataplane elements on compute nodes).
+hosts run the {rh-rhoso-short} data plane (data plane elements on compute nodes).
 
-The GitOps flow above describes *how* configuration is delivered. The diagram
-and list below describe *what* gets deployed:
+The preceding GitOps flow describes *how* GitOps delivers configuration. The
+following diagram and list describe *what* gets deployed:
 
-.RHOSO infrastructure topology
+.{rh-rhoso-short} infrastructure topology
 image::rhoso-gitops/rhoso-gitops-infrastructure.svg[{rhoso-gitops-pattern} infrastructure topology,700]
 
-* *OpenShift cluster* — control-plane nodes run OpenStack operators and
-  `OpenStackControlPlane` services
-* *Data plane hosts* — one or more {rhel-short} compute nodes run {rh-rhoso-short}
-  dataplane elements, connected to the control plane
+* *OpenShift cluster*: Control-plane nodes run OpenStack Operators and
+  `OpenStackControlPlane` services.
+* *Data plane hosts*: One or more {rhel-short} compute nodes run {rh-rhoso-short}
+  data plane elements and connect to the control plane.
 
 [id="rhoso-gitops-sync-waves"]
 == Application sync order
@@ -66,11 +75,11 @@ Child Applications deploy in sync-wave order when Argo CD reconciles the parent
 | Application | Purpose | Sync wave
 
 | `operator-dependencies`
-| Infrastructure operators (cert-manager, MetalLB, nmstate, observability)
+| Infrastructure Operators (cert-manager, MetalLB, nmstate, observability)
 | `-20`
 
 | `openstack-operator`
-| OpenStack operator subscription
+| OpenStack Operator subscription
 | `-20`
 
 | `openstack-operator-cr`
@@ -94,5 +103,5 @@ Child Applications deploy in sync-wave order when Argo CD reconciles the parent
 | `20`
 |===
 
-After changing overrides, confirm child apps in the Argo CD UI or with
+After you change overrides, confirm child apps in the Argo CD UI or with
 `oc get applications -n openshift-gitops`.