Validated Patterns

Pattern

RHOSO GitOps

Status Sandbox Sandbox

Resources

About the RHOSO GitOps pattern

Deploying Red Hat OpenStack Services on OpenShift 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 RHOSO from public Git through Argo CD. Manifests stay declarative and version-controlled, and Argo CD reconciles the cluster to match what the repository declares.

Pattern goals

The RHOSO GitOps pattern aims to:

  • Install the rhoso-gitops meta-chart through the Validated Patterns clustergroup and Red Hat OpenShift GitOps Operator

  • Create child Argo CD Applications that sync RHOSO stages from upstream openstack-k8s-operators/gitops (example/* Kustomize overlays)

  • Target one Red Hat OpenShift Container Platform cluster only; no managed-cluster spokes are in scope

  • Keep day-two changes reviewable in Git instead of one-off oc or Ansible runs

Red Hat technologies

The RHOSO GitOps pattern uses the following Red Hat products:

  • Red Hat OpenShift Container Platform

  • Red Hat OpenShift GitOps

  • Red Hat OpenStack Services on OpenShift

Cluster scope

Validated Patterns distinguishes between the initial cluster (where you install the pattern) and managed clusters (additional Red Hat OpenShift Container Platform clusters or hosts managed from that hub, for example through RHACM).

The RHOSO GitOps pattern is single-cluster only. It does not include multi-cluster support, spoke provisioning, or hub-to-spoke GitOps fan-out.

Table 1. Cluster scope
ScopeSupportedWhat applies

Initial cluster

Yes

Validated Patterns clustergroup (values-standalone.yaml), rhoso-gitops meta-chart, and child RHOSO Applications in rhoso-gitops-standalone

Managed clusters

None

Not in scope (spoke_support: false in pattern-metadata.yaml). The pattern does not define or deploy spoke sizing, policies, RHACM placement, or remote Argo CD instances

Sizing guidance under requirements.hub in the pattern repository applies to the single target cluster. Managed-cluster requirements (for example eventual consistency across spokes) do not apply to this pattern.

Support

This is a sandbox tier pattern. The community provides support on a best-effort basis. For details, see the support policy in the pattern repository.

RHOSO GitOps pattern architecture

The RHOSO GitOps pattern delivers RHOSO configuration through Argo CD Applications that the rhoso-gitops meta-chart creates. The pattern uses GitOps delivery through dual Argo CD namespaces, manages infrastructure topology, and converges deployment through retry policies.

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 RHOSO stages from the upstream openstack-k8s-operators/gitops repository (example/* Kustomize overlays).

The delivery path is:

  1. The Validated Patterns Operator reconciles the pattern clustergroup

  2. The parent rhoso-gitops Application runs in vp-gitops (Validated Patterns GitOps)

  3. The meta-chart renders child Applications in rhoso-gitops-standalone (dedicated Argo CD instance)

  4. The child applications sync upstream example/* overlays (Operators, networks, control plane, data plane) and converge through retry policies

RHOSO GitOps pattern GitOps application delivery
Figure 1. GitOps application delivery

The parent Application runs in vp-gitops. Child Applications in rhoso-gitops-standalone sync upstream Kustomize overlays. All child Applications deploy at sync-wave 0 and converge eventually through retry policies.

Dual Argo CD namespaces

The pattern uses two Argo CD namespaces:

  • The Validated Patterns Operator deploys the parent rhoso-gitops Application into vp-gitops (Validated Patterns GitOps).

  • The meta-chart creates child RHOSO Applications in rhoso-gitops-standalone, a dedicated Argo CD instance managed by the pattern (see applicationNamespace in the chart).

Infrastructure topology

An Red Hat OpenShift Container Platform cluster hosts the RHOSO control plane (OpenStack Operators and OpenStackControlPlane services on control-plane nodes). Separate RHEL hosts run the RHOSO data plane (data plane elements on compute nodes).

The GitOps delivery flow defines how configuration reaches the cluster. The infrastructure topology defines what gets deployed:

RHOSO GitOps pattern infrastructure topology
Figure 2. RHOSO infrastructure topology

  • OpenShift cluster: Control-plane nodes run OpenStack Operators and OpenStackControlPlane services.

  • Data plane hosts: One or more RHEL compute nodes run RHOSO data plane elements and connect to the control plane.

Deployment convergence

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 child retries (per syncPolicy.retry) until its upstream dependencies resolve and it converges eventually.

For the full list of child applications, their upstream paths, and links to the corresponding Red Hat OpenStack Services on OpenShift product documentation, see Configuration > Upstream applications.

After you change overrides, confirm child applications in the Argo CD UI or with oc get applications -n rhoso-gitops-standalone.

Edit this page Open a documentation issue

QUICKLINKS

CONTRIBUTE

STAY IN TOUCH

Validated Patterns

Validated Patterns are an evolution of how you deploy applications in a hybrid cloud. With a pattern, you can automatically deploy a full application stack through a GitOps-based framework. With this framework, you can create business-centric solutions while maintaining a level of Continuous Integration (CI) over your application.