How to manage Dynatrace-Operator upgrades in OpenShift?

[sivart_89]

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

[Michal_Gebacki]

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!

[sivart_89]

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.

[gopher]

@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.