Configuration

RHOSO GitOps pattern configuration

The rhoso-gitops meta-chart renders Argo CD Application resources. It does not deploy RHOSO workloads directly; Kustomize overlays in the upstream GitOps repository remain the source of truth.

Values file layers

The clustergroup application in values-standalone.yaml points Argo CD at charts/all/rhoso-gitops and layers pattern overrides from overrides/values-rhoso-gitops.yaml through extraValueFiles.

Table 1. Values file layers
Layer	File	Role
Pattern global	`values-global.yaml`	Pattern name, sync policy, singleArgoCD mode, custom ArgoCD health checks
Cluster group	`values-standalone.yaml`	Registers the `rhoso-gitops` application and namespaces
Chart defaults	`charts/all/rhoso-gitops/values.yaml`	Default `applications` map and chart-wide keys
Pattern overrides	`overrides/values-rhoso-gitops.yaml`	Pins upstream `repoURL`, `targetRevision`, and paths
Platform overrides	`overrides/values-AWS.yaml`	Optional platform-specific overrides (placeholder)

To change upstream Git content (revision, paths, or enabled applications), edit overrides/values-rhoso-gitops.yaml. The pattern syncs automatically if global.options.syncPolicy is set to Automatic in values-global.yaml.

Upstream applications

Child Argo CD Applications sync from openstack-k8s-operators/gitops at the revision pinned in overrides/values-rhoso-gitops.yaml.

The example/ overlays shipped in the upstream repository are reference samples only. They do not produce a working deployment on your infrastructure. To deploy RHOSO, point each application at your own Git overlay (see Pointing an application to your Git overlay).

Table 2. Default upstream applications
Application	Purpose	Upstream path	Red Hat OpenStack Services on OpenShift docs
`operator-dependencies`	Infrastructure Operators (cert-manager, MetalLB, nmstate, observability)	`example/dependencies`	RHOCP software requirements
`openstack-operator`	OpenStack Operator subscription	`example/openstack-operator`	Installing and preparing the OpenStack Operator
`openstack-operator-cr`	Main `OpenStack` custom resource	`example/openstack-operator-cr`	Installing and preparing the OpenStack Operator
`openstack-secrets`	Secure-backend sync (disabled by default)	not configured	Providing secure access to the RHOSO services
`openstack-networks`	Network configuration	`example/openstack-networks`	Preparing RHOSO networks
`openstack-controlplane`	`OpenStackControlPlane`	`example/openstack-controlplane`	Creating the control plane
`openstack-dataplane`	Data plane	`example/openstack-dataplane`	Creating the data plane

By default, the pattern enables all applications except openstack-secrets. Applications use automated sync with a retry policy to handle transient failures during deployment convergence.

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. This can cause unexpected changes in production.

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:

applications:
  openstack-operator:
    targetRevision: "v0.2.0"                # tag — recommended
  openstack-controlplane:
    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.

Disabling automated sync for an application

To switch a specific application to manual sync, override its syncPolicy without the automated key:

applications:
  openstack-dataplane:
    syncPolicy:
      syncOptions:
        - Prune=true

Disabling a deployment stage

To disable a deployment stage, set enabled to false for that application:

applications:
  openstack-dataplane:
    enabled: false

Setting a custom retry policy

To override the default retry policy for an application:

applications:
  openstack-controlplane:
    syncPolicy:
      automated:
        prune: true
        selfHeal: true
      retry:
        limit: 20
        backoff:
          duration: "10s"
          factor: 2
          maxDuration: "5m"

For more information about retry options, see the Argo CD automatic sync documentation.

Pointing an application to your Git overlay

To point an application at your own Git overlay, set repoURL, path, and targetRevision:

applications:
  openstack-controlplane:
    repoURL: "https://github.com/example/your-gitops.git"
    path: "environments/prod/controlplane"
    targetRevision: "main"

Adding Kustomize components

For example, add a secrets Operator component through operator-dependencies:

applications:
  operator-dependencies:
    kustomize:
      components:
        - "https://github.com/openstack-k8s-operators/gitops/components/secrets/vault-secrets-operator?ref=v0.2.0"

For Vault Secrets Operator and External Secrets Operator component URLs, see the upstream components/secrets README.

For standalone Helm usage and advanced chart examples, see the upstream rhoso-apps chart.

Edit this page Open a documentation issue