OpenShift – Exploring Operator Catalogs

Operators in OpenShift are managed through the Operator Lifecycle Manager (OLM), which defines how operators are packaged, installed, and upgraded. Sometimes, you’ll want to peek under the hood—examining which images an operator uses, what versions (bundles) exist, and which upgrade channels are available.

In this walkthrough, we’ll explore the OLM catalog for the OpenShift GitOps Operator, a popular operator that deploys Argo CD to manage GitOps workflows.

Step 1: Retrieve the OLM Catalog JSON

You can start by extracting the catalog JSON directly from Red Hat’s operator index image. The following command pulls down the catalog data and saves it locally:

podman run -it --rm --entrypoint /bin/cat \
  registry.redhat.io/redhat/redhat-operator-index:v4.19 \
  /configs/openshift-gitops-operator/catalog.json > gitops-catalog.json

Change the version respectively from v4.19 to your specific version you’re looking for.

This gives you a gitops-catalog.json file to explore with tools like jq.

Step 2: Delve into Related Images

Each operator bundle typically declares the related container images it depends on. You can extract this list with:

jq 'select(.relatedImages) | .name, .relatedImages' gitops-catalog.json

For GitOps, you’ll typically see images like:

• openshift-gitops-operator (the controller/operator itself)
• argocd_image
• argocd_dex_image (for authentication)
• argocd_redis_image (for caching)

This gives you visibility into all the moving parts that will be pulled into your cluster.

Step 3: Explore CSV Bundles

Every operator release is packaged as a Cluster Service Version (CSV) bundle. You can list the available versions with:

jq 'select(.schema == "olm.bundle")| .name' gitops-catalog.json

You’ll see versions like:

• openshift-gitops-operator.v1.9.2
• openshift-gitops-operator.v1.9.3
• openshift-gitops-operator.v1.9.4

This helps you track operator evolution and choose upgrade paths.

Step 5: Check Upgrade Channels

Operators are published across channels that define upgrade policies. List them with:

jq 'select(.schema == "olm.channel")| .name' gitops-catalog.json

For GitOps, you’ll see:

• “gitops-1.15”
• “gitops-1.16”
• “gitops-1.17”
• “latest”

These let you pin your clusters to a major version stream, ensuring predictable upgrades.

Why This Matters

Exploring OLM catalogs gives you:

• Transparency – see which images/operators are really being deployed.
• Upgrade control – understand which versions exist before moving forward.
• Audit readiness – validate components for security and compliance, especially in disconnected environments.

The OpenShift GitOps Operator is just one example, but the same approach works for any operator—logging, monitoring, service mesh, or others. By mastering a few jq tricks, you can demystify the contents of any OLM catalog and make more informed decisions when managing operators in OpenShift.