What happens when a Deployment is edited while a canary is being evaluated?

[mark-rushakoff]

I've looked through the docs a bit to find an answer, but I have not succeeded in finding it. Maybe it's there and I've missed it.

Suppose Version A of my Deployment is stable and receiving 100% of traffic. I edit the Deployment, and now Version B is in the canary state and receiving some fraction of traffic.

What happens when I edit the Deployment again and create Version C?

Is Canary B interrupted and does C take its place?

Or, does C sit in a "queue" and wait until B is finished evaluating? If yes, and I edit the Deployment one more time to create Version D, what happens next? Is C evaluated and then D, or does D "overwrite" Version C?

Hopefully my questions are clear here. I'm happy to clarify if not. Thanks.

[kingdonb]

If the canary deployment is updated in the middle of a progressing rollout, the canary weight is quickly reset to 0 and the progressing restarts from the beginning.

In the events output of kubectl describe canary depending on your deployment's name, you will see something like this message:

New revision detected! Restarting analysis for podinfo.test

There is no queueing, the canary progressing just restarts. I was able to answer this through testing on a local cluster, with a slight variation on the guide here, I just tried it: https://docs.flagger.app/tutorials/nginx-progressive-delivery

There are two deployments in play when Flagger canary is used. The original deployment becomes "the canary" deployment, and only receives traffic when Flagger has shifted some traffic to it. The second deployment is tagged "primary" and this is where the promoted version of your deployment lives, where all traffic is served from whenever a rollout is not progressing.

So there is no mechanism for queueing, and there is no promotion without successful completion of the progressing state.

[mccurdyc]

Hello! 👋 I've really enjoyed using Flagger so far! I have one question to ensure I'm understanding behavior correctly.

(Let me know if I should open a separate Issue since this question may be specific to A/B Deployments and configmaps).

My question is mostly revolved around how a configmap change is promoted, specifically when using an A/B Deployment strategy.

TL;DR - I'm fairly certain I've experienced Flagger "immediately promote" a change when I've done two releases in quick (relative; depends on intervals and iterations) succession.

In the comment immediately above, it states the following (emphasis my own): "If the canary deployment is updated in the middle of a progressing rollout, the canary weight is quickly reset to 0 and the progressing restarts from the beginning.". Is "canary weight" referring to an annotation on the canary ingress, for example? Because the immediate phrase "the progressing restarts from the beginning" makes me think it's referring to progression and not traffic "weight".

As described above, but specifically referring to configmaps here:

1. Release a change; let's call this "Canary 1"
2. Assume Canary 1 is at 90% progression
3. Release another change; let's call this "Canary 2". Canary 1 is still at 90%.
   • IMMEDIATELY updates the canary configmap with Canary 2's change
   • ^^ indicates that Flagger is aware of the change, since it's responsible for updating the canary configmap.

Q: Is it possible here that the Canary 2 configmap is updated BEFORE the progression of Canary 1 is reset to 0%?

4. Canary 1 is now in the promote phase; and promotes the canary configmap
   • However, while you expect that it is promoting the configmap with Canary 1 values, it's actually promoting Canary 2 values.

Thank you!