You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Good afternoon, I have a rollout with the canary strategy and I change it to blueGreen, when trying to change the strategy the rollout appears inconsistent, in the argo rollout dashboard it is observed that it cannot be promoted and in the argo rollout logs it is shown that skips the changes. When applying new changes to the application, it can be observed in the status of the rollout resource that there are old replicas in canary and a new one in bluegreen and it has come to the case that a replica that does not have active pods is placed productive, which makes it not work. the application. I am using istio as trafficmanager.
It should be noted that to make the change from canary to bluegreen, everything is conditioned for its operation (service, virtualservice, destination) of istio. If a 0 application is deployed with bluegreen it works perfectly.
To Reproduce
To reproduce it you have to create a rollout with the canary method. When at least one replica is active, change the strategy to BlueGreen.
Expected behavior
The ideal would be to be able to change from Canary to bluegreen with everything in the new format (service, virtualservice, destination rules) and place the corresponding replica, eliminating all references to canary.
Screenshots
Version
argocd v2.9.3
argorollout v1.6.6
istio 1.17.2
Logs
time="2024-03-06T18:41:01Z" level=info msg="Started syncing rollout" generation=399 namespace=backend resourceVersion=814577988 rollout=frontend-backofficev2
time="2024-03-06T18:41:01Z" level=info msg="Reconciling stable ReplicaSet 'frontend-backofficev2-598dd79d84'" namespace=backend rollout=frontend-backofficev2
time="2024-03-06T18:41:01Z" level=info msg="Reconciling 2 old ReplicaSets (total pods: 2)" namespace=backend rollout=frontend-backofficev2
time="2024-03-06T18:41:01Z" level=info msg="Skip scale down of older RS 'frontend-backofficev2-58b567f796': still referenced" namespace=backend rollout=frontend-backofficev2
time="2024-03-06T18:41:01Z" level=info msg="Skip scale down of older RS 'frontend-backofficev2-5d4b65dc5c': still referenced" namespace=backend rollout=frontend-backofficev2
time="2024-03-06T18:41:01Z" level=info msg="No status changes. Skipping patch" generation=399 namespace=backend resourceVersion=814577988 rollout=frontend-backofficev2
Message from the maintainers:
This error only affects the service if the change is made from canary to bluegreen or bluegreen to canary.
The text was updated successfully, but these errors were encountered:
Checklist:
Describe the bug
Good afternoon, I have a rollout with the canary strategy and I change it to blueGreen, when trying to change the strategy the rollout appears inconsistent, in the argo rollout dashboard it is observed that it cannot be promoted and in the argo rollout logs it is shown that skips the changes. When applying new changes to the application, it can be observed in the status of the rollout resource that there are old replicas in canary and a new one in bluegreen and it has come to the case that a replica that does not have active pods is placed productive, which makes it not work. the application. I am using istio as trafficmanager.
It should be noted that to make the change from canary to bluegreen, everything is conditioned for its operation (service, virtualservice, destination) of istio. If a 0 application is deployed with bluegreen it works perfectly.
To Reproduce
To reproduce it you have to create a rollout with the canary method. When at least one replica is active, change the strategy to BlueGreen.
Expected behavior
The ideal would be to be able to change from Canary to bluegreen with everything in the new format (service, virtualservice, destination rules) and place the corresponding replica, eliminating all references to canary.
Screenshots
Version
argocd v2.9.3
argorollout v1.6.6
istio 1.17.2
Logs
Message from the maintainers:
This error only affects the service if the change is made from canary to bluegreen or bluegreen to canary.
The text was updated successfully, but these errors were encountered: