Allow retrying rollout without scaling down canary pods

[bpoland]

Summary

Right now, Argo Rollouts provides the abortScaleDownDelaySeconds to keep the canary pods scaled up for a period of time after an aborted deployment. I think this was designed to provide enough time for the traffic split to take effect and all traffic to be sent back to the stable version.

However, it would also be useful if retrying the rollout could reuse those scaled-up pods. Let's say you abort a rollout with abortScaleDownDelaySeconds: 600 or longer so the canary pods stay around for quite a while after aborting. If you retry the deployment, rollouts reuses the replicaset but starts at the beginning of the canary steps which means that all but one of the canary pods gets scaled down, and then the pods will get scaled back up again as it progresses through the steps.

Note that my rollout steps use setCanaryScale so perhaps this is only an issue when using that, but it would be nice if setCanaryScale (and setWeight if this isn't already the case) would only increase the number of pods as necessary (not decrease). So once the deployment is retried, it would see that there were enough pods and just stay at the higher number until the canary steps needed more.

---

Message from the maintainers:

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

[github-actions]

This issue is stale because it has been open 60 days with no activity.

[bpoland]

Hi, I hope this can still be done. I think it would be a useful improvement :)

[alexef]

I see a bit of overlap between this feature and #1779

[bpoland]

I see a bit of overlap between this feature and #1779

Hmm, it seems like that is covering something different (minimum pods during a rollout). With this ticket I'd like a way to reuse pods for the new version that are already running if we want to retry the rollout.

[github-actions]

This issue is stale because it has been open 60 days with no activity.

[bpoland]

Please don't close this :)

[github-actions]

This issue is stale because it has been open 60 days with no activity.