When using BlueGreen, can a ReplicaSet demoted after Promotion be left in Running state?

[Himenon]

I would like to deploy an application using a combination of Argo CD and Argo rollouts. As I proceeded with these verifications, I noticed the following:

1. Maintain bluegreen manifest in a GitHub repository.
   • Make the image argoproj/rollouts-demo:red.
   • autoPromotionEnabled is false.
2. Refer to the aforementioned manifest in ArgoCD.
   • argoproj/rollouts-demo:red will be deployed to the cluster.
3. Update the image version to yellow.
   • This is equivalent to argocd app sync.
4. Watching with kubectl argo rollouts get rollout [target] --watch command, we can see that two types of ReplicaSet are created: preview replica and active replica.
5. Run PROMOTE from the Dashboard of Argo Rollout
6. The PROMITE will promote the replica from preview to active, but the replica demoted from active to preview will be ScaledDown and in the state of exit.

What I would like to achieve is to only ScaleDown the demoted replica and leave it in the Running state.

Is this feasible?

[jessesuen]

What I would like to achieve is to only ScaleDown the demoted replica and leave it in the Running state.

I don't quite understand this desire. Once the yellow version is promoted, the Rollout is back at a fully promoted/steady state (aka Healthy), so it would be innacurate to report it otherwise. Can you explain the use case? What do you mean by "Running?"

[Himenon]

To be more specific, the current BlueGreen flow can be shown in the following table

	active	preview	Operation
1	red/3	-	initial state
2	red/3	yellow/2	deploy yellow
3	red/3	yellow/3	exec PROMOTION
4	yellow/3	red/3	Switch
5	yellow/3	red/0	Scale down preview

The following meanings are given

• red/3 = argoproj/rollouts-demo:red , replica 3
• yellow/2 = argoproj/rollouts-demo:yellow , replica 3

What I want to ask is that in state 5, the preview environment is not accessible because the number of replicas is 0. is it possible to keep the 5th preview environment accessible by setting its state to something like red/2?

[jessesuen]

I see. We have a feature which addresses part of you are asking but not fully. There is an option, blueGreen.scaleDownDelaySeconds which delays scaledown of the old ReplicaSet for a number of seconds. The default delay is 30 seconds.

https://argoproj.github.io/argo-rollouts/features/bluegreen/#scaledowndelayseconds

However, there is no feature to control the size of the old replicaset. In other words, if you choose to delay scale down of the old ReplicaSet, it will be fully scaled to the rollout's spec.replicas. In your question, you wanted red/2, but the feature only allows for red/3

Note that part of the scaleDownDelaySeconds feature is that if the Rollout is subsequently updated to the old pod spec, we consider this a rollback and the bluegreen will skip pre/post-analysis and ignore autoPromotionEnabled: false.

The use case when implementing this feature was: users wanted to do a blue-green update. But leave the old stack up and running for some extended period of time in case they needed to rollback to it, and not have to wait for auto-scaling/pod provisioning/pod startup time.

[Himenon]

I have read the following rc

https://github.com/argoproj/argo-rollouts/releases/tag/v1.1.0-rc1

I think I can achieve this by specifying abortScaleDownDelaySeconds: 0. In that case I think this discussion can be closed.