topic Re: How to manage dynatrace-operator upgrades in OpenShift in Container platforms

How to manage Dynatrace-Operator upgrades in OpenShift?

sivart_89 — Wed, 17 Dec 2025 11:34:03 GMT

I'm trying to use ArgoCD to manage upgrades of the dynatrace operator in OpenShift. My subscription yaml is below. Everything I have been seeing is that startingCSV refers to what version to start at when a fresh install is done. Lets say for example I want to upgrade to version 1.7.0 how can I do that without uninstalling and reinstalling the subscription? I only see a install plan for 1.7.1, it seems OpenShift always only has the latest version available to go to but I don't want to always be force to go to the latest version.

apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: labels: operators.coreos.com/dynatrace-operator.dynatrace: "" name: dynatrace-operator namespace: dynatrace spec: channel: alpha installPlanApproval: Manual name: dynatrace-operator source: certified-operator-index sourceNamespace: openshift-marketplace startingCSV: dynatrace-operator.v1.6.2

Re: How to manage dynatrace-operator upgrades in OpenShift

Michal_Gebacki — Tue, 16 Dec 2025 15:58:11 GMT

Hi, @sivart_89!

Is this Dynatrace Documentation page helping to address your issue in any way?

-> Update or uninstall Dynatrace Operator

Please let us know, thank you!

Re: How to manage dynatrace-operator upgrades in OpenShift

sivart_89 — Tue, 23 Dec 2025 19:52:59 GMT

Hi @Michal_Gebacki, no this doc does not help any. I am looking for how I can do an upgrade using more of a gitops approach, using ArgoCD to pick up the change I push to my GitHub repo then applying the changes to the cluster. Specifically, my question is around using ArgoCD in OpenShift, how you can setup things to have ArgoCD upgrade the dynatrace operator to a specific version.

Re: How to manage dynatrace-operator upgrades in OpenShift

gopher — Wed, 24 Dec 2025 05:53:17 GMT

@sivart89 it will really depend on how you have set up your deployment structure in Argo.
You don't really specify if you use Helm or Manifest approach.

For helm it will look something like this

Pin targetRevision in the Argo CD Application to the desired Helm chart version (e.g., 1.7.0 → 1.7.2).
Update the chart in your OpenShift OCI registry
Commit the updated targetRevision and any new valuesObject changes to your Git repo.
Argo CD will:
- Pull the new chart version.
- Apply Helm upgrade logic (preserves stateful resources, runs hooks).
CRDs:
- If installCRD: true in Helm values:
  - Helm will upgrade CRDs automatically (non-destructive if CRDs are backward-compatible).
- If installCRD: false:
  - You must update CRDs manually in Git and sync via Argo CD before upgrading the Operator chart.
  - you can use sync waves or PreSync hooks to ensure CRDs apply first.

For Manifests it will look something like this

Replace manifests with those from the new Operator release.

Commit and push.

Argo CD will:
- Apply changes declaratively.
CRDs:
- Update CRD YAMLs in Git first.

Sync CRDs before Operator manifests (use sync waves or PreSync hooks).

The instructions provided before are correct and relevant, you just need to massage it to be relevant for your CD tool and do the groundwork for your deployment approach.

I use both Flux and Argo depending on the k8s cluster being used. fundamentals and approach are the same, the "how i do it" are just manipulated for the relevant tool. You will know best as to what you have set up and how to do it relevant to your environment.