Alter the logic of "updated" pods in WaitForControlledPodsRunning measurement #1547
Labels
kind/bug
Categorizes issue or PR as related to a bug.
lifecycle/frozen
Indicates that an issue or PR should not be auto-closed due to staleness.
Before #1035 was merged,
WaitForControlledPodsRunning
barrier was simply waiting for all pods specified by a label selector to reach the running state. Such approach doesn't take into account potential rolling updates of pods belonging to certain deployment(s). #1035 introduced an additional check that the appropriate pods' specs match the deployment's template spec as a heuristic to ensure that we're finished with the rolling updates.This approach doesn't work when there's an additional server logic altering the pods' specs, however. There are two possible ideas how to improve this:
WaitForControllerPodsRunning
's parameter next tocheckIfPodsAreUpdated
like "fieldToCheck: 'spec.containers[0].env[0]
'.Option 2 seems to be easier to use, but I'm not sure if we can implement this without larger CL's refactoring (e.g. do we store old version of each deployment)?
Option 1 seems to be easier to implement and is more explicit, but requires some manual changes for all
WaitForControlledPodsRunning
that wants to use "pod updated" feature.The text was updated successfully, but these errors were encountered: