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, clustergroup chart version
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, enable or disable applications), edit overrides/values-rhoso-gitops.yaml and sync the pattern (or let automated sync reconcile, per global.options.syncPolicy 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 (`path: TODO`)	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"

Refer to the Argo CD automatic sync documentation for available retry options.

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.

Secret zero (bootstrap credential)

RHOSO GitOps often uses a secure store (for example Vault). Do not store the bootstrap credential in Git. Complete the following steps:

Configure the secret wiring before deploying the pattern:
1. Add a Kustomize overlay in your Git repository for secret wiring (non-sensitive manifests only).
2. Enable and configure applications.openstack-secrets in overrides/values-rhoso-gitops.yaml (enabled: true, repoURL, path, targetRevision, optional kustomize patches).
3. Install the secrets Operator through operator-dependencies by using kustomize.components URLs from the upstream secrets components.
While the pattern is deploying, wait for the openstack namespace to appear (an earlier Argo CD application creates it). Then inject the bootstrap Secret out of band in a separate terminal. If you are working remotely, use tmux or screen so you can monitor the deployment and inject the secret in parallel.
Do not create the openstack namespace manually. Argo CD creates it during deployment, and a pre-existing namespace causes ownership conflicts.
Poll for the namespace and inject the secret as soon as it appears:
```
$ while ! oc get namespace openstack &>/dev/null; do sleep 10; done
$ oc create secret generic <secret_name> \
    --from-literal=<key>=<value> \
    -n openstack --dry-run=client -o yaml | oc apply -f -
```

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

Edit this page Open a documentation issue