Summary

Per this check https://github.com/argoproj/argo-rollouts/blob/master/rollout/sync.go#L947, we're only able to fully promote the rollout for a canary when ALL pods in the new replicaset are available. However, we run systems like karpenter that are also running consolidation and the like up to the point of our PDB maxUnavailable, which can induce serious delay in the Rollout being able to fully complete. It would be fantastic if Argo-Rollouts was instead checking against the PDB value or in some way had a toleration for a certain amount of ongoing churn, or would otherwise allow this full promote to go through, even when fewer pods than the rollout spec declares are available.

Use Cases

We would generally use this across all of our rollouts, as we run a large amount of consolidation process that kicks in even as we perform gradual rollouts. Our current workaround is to disable consolidation on pods that are participating in the active deploy, but this can hurt our efficiency.

Message from the maintainers:

Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.