Checklist:
Describe the bug
After upgrading the Argo Rollouts Helm chart from version 2.40.5 to 2.40.8 (which bumped the rollouts controller from 1.8.3 to 1.9.0), all existing Rollout objects in the cluster unexpectedly changed their status to Progressing.
Consequently, all pods managed by these Rollouts began to be recreated. This behavior is highly disruptive as we are running Argo Rollouts in a critical production environment. We need to understand if this is expected behavior for this upgrade path and if there is a way to upgrade to 1.9.0 without triggering pod recreations for already healthy Rollouts.
To Reproduce
- Have a Kubernetes cluster running Argo Rollouts v1.8.3 (via Helm chart v2.40.5) with several active Rollout objects in a
Healthy state.
- Upgrade the Helm chart to v2.40.8 (upgrading the controller to v1.9.0).
- Observe that immediately after the controller restart/upgrade, all Rollout objects change status to
Progressing.
- Observe that the controller starts recreating all pods managed by those Rollouts.
Expected behavior
Upgrading the Argo Rollouts controller version should not automatically trigger a rolling update or pod recreation for existing Rollouts that were already in a Healthy state, unless there was a specific change to the Rollout spec or an explicit manual intervention.
Screenshots
- Rollout objects in
Healthy state before the upgrade:
- Rollout objects changing to
Progressing state after bumping the controller to v1.9.0:
- Pods being terminated and recreated by the rollout controller:
Version
- Previous Version: v1.8.3 (Helm Chart 2.40.5)
- Target Version: v1.9.0 (Helm Chart 2.40.8)
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.
Checklist:
Describe the bug
After upgrading the Argo Rollouts Helm chart from version
2.40.5to2.40.8(which bumped the rollouts controller from1.8.3to1.9.0), all existing Rollout objects in the cluster unexpectedly changed their status toProgressing.Consequently, all pods managed by these Rollouts began to be recreated. This behavior is highly disruptive as we are running Argo Rollouts in a critical production environment. We need to understand if this is expected behavior for this upgrade path and if there is a way to upgrade to
1.9.0without triggering pod recreations for already healthy Rollouts.To Reproduce
Healthystate.Progressing.Expected behavior
Upgrading the Argo Rollouts controller version should not automatically trigger a rolling update or pod recreation for existing Rollouts that were already in a
Healthystate, unless there was a specific change to the Rollout spec or an explicit manual intervention.Screenshots
Healthystate before the upgrade:Progressingstate after bumping the controller to v1.9.0:Version
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.