Upgrading Dynatrace Operator v1.4.0 to v1.9.0 & Migrating to Cloud-Native Full-Stack on OpenShift

[Aboud1]

Hi Dynatrace Community,

We're preparing to migrate our OpenShift cluster from Classic Full-Stack to Cloud-Native Full-Stack using the Dynatrace Operator.

Current setup:

• Operator: v1.4.0
• Target: v1.9.0 (OLM generated a direct upgrade path)
• OpenShift cluster with tainted master/control-plane and storage nodes.

I have a few questions for anyone who has already done this migration:

1. Has anyone upgraded the Operator directly from v1.4.0 → v1.9.0 using OLM? Any issues during the upgrade or CRD conversion?
2. For the CSI Driver, did you manually apply the openshift-csi.yaml (with your custom tolerations) before switching the DynaKube to cloudNativeFullStack, or did you let the Operator handle it?
3. After switching from classicFullStack to cloudNativeFullStack, did you need to restart your application deployments (e.g., rollout restart) for monitoring injection to take effect, or was everything handled automatically?

Any lessons learned or gotchas would be greatly appreciated.

Thanks.

Aboud

[sujit_k_singh · Accepted solution]

Hi @Aboud1 

I haven't done this exact v1.4.0 → v1.9.0 upgrade, but I've worked with OpenShift deployments and Dynatrace Operator implementations across a number of clusters. A few observations that may help:

OLM Upgrade v1.4.0 → v1.9.0

From what I've seen across multiple OCP environments, OLM-managed direct upgrades generally work, but a few things to be cautious about:
- Back up your DynaKube CR before triggering the upgrade the CRD schema changes between these versions and while OLM handles the conversion webhook, having a rollback point is always wise.
- After the Operator pod restarts, verify the new CRD version is registered
- If you have any custom ClusterRole, RoleBinding, or SecurityContextConstraints associated with the Dynatrace Operator, it's worth validating them after the upgrade. In OpenShift environments, I've occasionally seen custom RBAC/SCC configurations require attention following platform or operator upgrades, so it's a good post-upgrade check

 CSI Driver & Custom Tolerations

Don't rely on the Operator to automatically handle all taint scenarios. On clusters with tainted master/control-plane or storage nodes, I'd recommend reviewing tolerations carefully and ensuring they are applied wherever required. In similar OpenShift environments, I've seen CSI-related scheduling issues become visible only after enabling cloudNativeFullStack.

One thing I'd validate before the cutover is that the CSI driver is successfully running on all expected node types. Since CSI becomes a key dependency for cloudNativeFullStack, any missed tolerations can lead to injection or volume-related issues after the switch.

Rollout Restart After Switching

Yes, you will need to restart your application deployments. Cloud-Native Full-Stack uses init-container injection via the webhook/CSI driver, which only triggers at pod creation time. Existing running pods monitored by the Classic daemonset won't automatically switch to the new injection method.

Good luck with the cutover let us know how it goes!

Thanks,

Sujit

[Aboud1]

Thanks a lot, Sujit. I really appreciate the detailed response.

Your explanation about the rollout restart makes sense and actually aligns with what I observed during a previous migration on our HA cluster. We had to perform a rollout restart before the applications were injected correctly after switching the monitoring mode.

We'll also make sure to back up the DynaKube CR, verify the CRDs after the OLM upgrade, and double-check the CSI tolerations on our tainted nodes before the migration.

I'll share the outcome here once we've completed the upgrade. Thanks again for taking the time to share your experience!