Pattern

RHOSO GitOps

Status

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 the stack must be upgraded or reproduced.

The RHOSO GitOps pattern addresses that by driving RHOSO 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.

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

Red Hat OpenShift Container Platform
Red Hat OpenShift GitOps
Red Hat OpenStack Services on OpenShift

Cluster scope

Validated Patterns distinguish between the initial cluster (where the pattern is installed) 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 provide multi-cluster support, spoke provisioning, or hub-to-spoke GitOps fan-out.

Table 1. Cluster scope
Scope	Supported	What applies
Initial cluster	Yes	Validated Patterns clustergroup (`values-standalone.yaml`), rhoso-gitops meta-chart, and child RHOSO Applications in `openshift-gitops`
Managed clusters	None	Not in scope (`spoke_support: false` in `pattern-metadata.yaml`). No spoke sizing, policies, RHACM placement, or remote Argo CD instances are defined or deployed

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 Validated Pattern. Support is provided by the community on a best-effort basis. For details, see the support policy in the pattern repository.

RHOSO GitOps pattern architecture

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:

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 (Red Hat OpenShift GitOps)
Child apps sync upstream example/* overlays in order (operators, networks, control plane, dataplane)

RHOSO GitOps pattern GitOps application delivery

Figure 1. GitOps application delivery and sync-wave ordering

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.

Dual Argo CD namespaces

The pattern operator deploys the parent rhoso-gitops Application into vp-gitops (Validated Patterns GitOps).
Child RHOSO Applications are created in openshift-gitops (Red Hat OpenShift GitOps operator), per the meta-chart defaults.

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 (dataplane elements on compute nodes).

The GitOps flow above describes how configuration is delivered. The diagram and list below describe 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 dataplane elements, connected to the control plane

Application sync order

Child Applications deploy in sync-wave order when Argo CD reconciles the parent rhoso-gitops Application:

Application Purpose Sync wave

Application	Purpose	Sync wave
`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`

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 changing overrides, confirm child apps in the Argo CD UI or with oc get applications -n openshift-gitops.

Next steps

Edit this page Open a documentation issue