Update rhoso-gitops docs for automated sync and dedicated namespace

content/patterns/rhoso-gitops/troubleshooting.adoc

@@ -53,22 +53,22 @@ The pattern uses two Argo CD namespaces. List applications in each namespace:
 $ oc get applications -n vp-gitops
 ----
 
-. List applications in `openshift-gitops`:
+. List applications in `rhoso-gitops-standalone`:
 +
 [source,terminal]
 ----
-$ oc get applications -n openshift-gitops
+$ oc get applications -n rhoso-gitops-standalone
 ----
 
 . 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 rhoso-gitops-standalone
 ----
 
-Use the Argo CD UI in the `openshift-gitops` namespace to review sync waves,
-resource health, and diff details for upstream overlays.
+Use the Argo CD UI in the `rhoso-gitops-standalone` namespace to review
+application status, resource health, and diff details for upstream overlays.
 
 [id="rhoso-gitops-check-pods"]
 == Checking pod status
@@ -103,7 +103,8 @@ The following known issues can affect pattern deployment:
   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
-  `ClusterServiceVersions` (CSVs) before later sync waves run.
+  `ClusterServiceVersions` (CSVs). Other applications retry automatically
+  until their dependencies are satisfied.
 
 For community support, open an issue in the
 link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/issues[pattern repository].

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

@@ -52,7 +52,7 @@ fan-out.
 | Yes
 | {solution-name-upstream} clustergroup (`values-standalone.yaml`),
   *rhoso-gitops* meta-chart, and child {rh-rhoso-short} Applications in
-  `openshift-gitops`
+  `rhoso-gitops-standalone`
 
 | Managed clusters
 | None

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

@@ -7,7 +7,7 @@
 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.
+and deployment convergence before you deploy or customize the pattern.
 
 [id="rhoso-gitops-gitops-delivery"]
 == GitOps delivery flow
@@ -23,18 +23,18 @@ The delivery path is:
 . 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)
+. The meta-chart renders child Applications in `rhoso-gitops-standalone`
+  (dedicated Argo CD instance)
+. The child apps sync upstream `example/*` overlays (Operators,
+  networks, control plane, data plane) and converge through retry policies
 
-.GitOps application delivery and sync-wave ordering
+.GitOps application delivery
 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
-plane.
+`rhoso-gitops-standalone`, and the upstream Kustomize overlays they sync.
+All child Applications deploy at sync-wave 0 and converge eventually through
+retry policies.
 
 [id="rhoso-gitops-dual-argocd"]
 == Dual Argo CD namespaces
@@ -43,8 +43,9 @@ 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.
+* Child {rh-rhoso-short} Applications are created in *`rhoso-gitops-standalone`*,
+  a dedicated Argo CD instance managed by the pattern (see `applicationNamespace`
+  in the chart).
 
 [id="rhoso-gitops-infrastructure-topology"]
 == Infrastructure topology
@@ -64,44 +65,39 @@ image::rhoso-gitops/rhoso-gitops-infrastructure.svg[{rhoso-gitops-pattern} infra
 * *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
+[id="rhoso-gitops-deployment-convergence"]
+== Deployment convergence
 
-Child Applications deploy in sync-wave order when Argo CD reconciles the parent
-*rhoso-gitops* Application:
+All child Applications deploy at sync-wave `0` (the default) when Argo CD
+reconciles the parent *rhoso-gitops* Application. Argo CD launches every child
+simultaneously; each retries (per `syncPolicy.retry`) until its upstream
+dependencies are satisfied and converges eventually.
 
-[cols="2,3,1",options="header"]
+[cols="2,3",options="header"]
 |===
-| Application | Purpose | Sync wave
+| Application | Purpose
 
 | `operator-dependencies`
 | Infrastructure Operators (cert-manager, MetalLB, nmstate, observability)
-| `-20`
 
 | `openstack-operator`
 | OpenStack Operator subscription
-| `-20`
 
 | `openstack-operator-cr`
 | Main `OpenStack` custom resource
-| `-15`
 
 | `openstack-secrets`
 | Secure-backend sync (disabled by default)
-| `-10`
 
 | `openstack-networks`
 | Network configuration
-| `0`
 
 | `openstack-controlplane`
 | `OpenStackControlPlane`
-| `10`
 
 | `openstack-dataplane`
 | Data plane
-| `20`
 |===
 
 After you change overrides, confirm child apps in the Argo CD UI or with
-`oc get applications -n openshift-gitops`.
+`oc get applications -n rhoso-gitops-standalone`.

modules/rhoso-gitops/rhoso-gitops-configuration.adoc

@@ -53,39 +53,49 @@ link:https://github.com/openstack-k8s-operators/gitops[openstack-k8s-operators/g
 at the revision pinned in `overrides/values-rhoso-gitops.yaml`.
 
 .Default upstream applications
-[cols="2,2,1",options="header"]
+[cols="2,2,1,1",options="header"]
 |===
-| Argo CD application | Upstream path | Enabled
+| Argo CD application | Upstream path | Enabled | Sync
 
 | `operator-dependencies`
 | `example/dependencies`
 | Yes
+| Automated
 
 | `openstack-operator`
 | `example/openstack-operator`
 | Yes
+| Automated
 
 | `openstack-operator-cr`
 | `example/openstack-operator-cr`
 | Yes
+| Automated
 
 | `openstack-secrets`
 | not configured (`path: TODO`)
 | No
+| Automated
 
 | `openstack-networks`
 | `example/openstack-networks`
 | Yes
+| Automated
 
 | `openstack-controlplane`
 | `example/openstack-controlplane`
 | Yes
+| Automated
 
 | `openstack-dataplane`
 | `example/openstack-dataplane`
 | Yes
+| Automated
 |===
 
+All applications include a default retry policy to handle transient failures
+during deployment convergence.
+
 For product, framework, upstream Git, and Operator versions, see the pattern
 repository
 link:https://github.com/validatedpatterns-sandbox/rhoso-gitops/blob/main/VERSIONS.md[VERSIONS.md]
@@ -94,21 +104,46 @@ file.
 [id="rhoso-gitops-pin-revision"]
 == Pinning a different upstream revision
 
+Child applications use *automated sync* by default: Argo CD reconciles them
+whenever the upstream Git repository changes. If `targetRevision` points to a
+branch name like `main` or `HEAD`, any push to that branch triggers an automatic
+deployment, which can cause unexpected changes in production.
+
+[IMPORTANT]
+====
+Always pin `targetRevision` to a *tag* or *commit hash* for stability.
+====
+
 In `overrides/values-rhoso-gitops.yaml`, set `targetRevision` for each
 application that you want to pin:
 
 [source,yaml]
 ----
 applications:
   openstack-operator:
-    targetRevision: "v0.2.0"
+    targetRevision: "v0.2.0"                # tag — recommended
   openstack-controlplane:
-    targetRevision: "v0.2.0"
+    targetRevision: "abc123def456"           # commit hash — also safe
 ----
 
 Apply the same key under every application you want on that revision, or only
 the entries that you want to change; unspecified keys keep chart defaults.
 
+[id="rhoso-gitops-disable-automated-sync"]
+== Disabling automated sync for an application
+
+To switch a specific application to manual sync, override its `syncPolicy`
+without the `automated` key:
+
+[source,yaml]
+----
+applications:
+  openstack-dataplane:
+    syncPolicy:
+      syncOptions:
+        - Prune=true
+----
+
 [id="rhoso-gitops-disable-stage"]
 == Disabling a deployment stage
 
@@ -121,6 +156,31 @@ applications:
     enabled: false
 ----
 
+[id="rhoso-gitops-custom-retry"]
+== Setting a custom retry policy
+
+To override the default retry policy for an application:
+
+[source,yaml]
+----
+applications:
+  openstack-controlplane:
+    syncPolicy:
+      automated:
+        prune: true
+        selfHeal: true
+      retry:
+        limit: 20
+        backoff:
+          duration: "10s"
+          factor: 2
+          maxDuration: "5m"
+----
+
+Refer to the Argo CD
+link:https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/#automatic-sync-semantics[automatic sync documentation]
+for available retry options.
+
 [id="rhoso-gitops-repoint-overlay"]
 == Pointing an application to your Git overlay
 

modules/rhoso-gitops/rhoso-gitops-deploying.adoc

@@ -91,11 +91,11 @@ $ ./pattern.sh make install
 $ oc get applications -n vp-gitops
 ----
 
-. List Argo CD applications in `openshift-gitops`:
+. List Argo CD applications in `rhoso-gitops-standalone`:
 +
 [source,terminal]
 ----
-$ oc get applications -n openshift-gitops
+$ oc get applications -n rhoso-gitops-standalone
 ----
 
 . After install, run the pattern health check: