-
Notifications
You must be signed in to change notification settings - Fork 720
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flagger and Flux gitops workflow in the case of cluster rebuilds #1577
Comments
Any ideas anyone? |
You can use version 1.36.1 of Flagger to see if it solves this problem. |
Unfortunately, that doesn't solve the problem |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi Team,
I have tried looking for a similar issue addressing the same problem but could not find one.
Describe the bug
My team deploys all manifests using Flux and we don't prefer doing it through
kubectl
. We are keen on using Flagger for our canary releases along with Flux but we have faced a peculiar challenge as our clusters need to be rebuilt very often.Steps
v1
v2
v1 -> v2
v2
even though promotion was not complete (This is the problem!)Expected behavior
This causes the limitation where Flagger & Flux don't know that the promotion process was interrupted due to a cluster rebuild i.e. no state of the promotion process is saved.
Possible solutions :-
Canary.spec
so no change in image tag is necessaryv2
, zero traffic is sent to itPlease do let me know if there are better ways to solve this corner case. Any help would be greatly appreciated!
Thanks in advance.
Additional context
The text was updated successfully, but these errors were encountered: