How to guarantee that a phase
belongs to a the current generation?
#2873
Unanswered
WillSewell
asked this question in
Q&A
Replies: 1 comment 1 reply
-
Hey Will appreciate this is dead old, so not expecting a response, but what do you mean about this comment?
In the latest version of Argo v1.7.2 it looks like the update is an atomic patch operation. It looks the same in an older version too v1.2.2. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We want to track the progress of a rollout. We do this by first polling the
Rollout.status.workloadGeneration
field until it matches the generation returned when the pod spec was updated.Then we poll the
Rollout.status.phase
until it is either Degraded/Paused/Healthy (i.e. no longer Progressing).The problem is, the update of
status.workloadGeneration
and the update ofstatus.phase
isn't atomic in all cases. So it's possible that we read the newstatus.workloadGeneration
but thestatus.phase
from the previous generation.Example controller logs where it first updates
status.workloadGeneration
and then updatesstatus.phase
:Given this, I'm not sure how we can guarantee the phase we are reading is part of the desired generation. Is there some way of doing this, or an alternative way of satisfying our use case that we might not have considered? We could workaround this by adding some delay between reading the desired generation, and polling for the `status.phase, but I'd rather not if there was a less brittle alternative 🙂
Beta Was this translation helpful? Give feedback.
All reactions