scheduler: DesiredCanaries can be set on every pass safely #8456
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The reconcile loop sets
DeploymentState.DesiredCanaries
only on the first pass through the loop and if the job is not paused/pending. In MRD, deployments will make one pass though the loop while "pending", and were not ever gettingDesiredCanaries
set. We can't set it in the initialDeploymentState
constructor because the first pass through setting up canaries expects it's not there yet. However, this value is static for a given version of a job because it's coming from the update stanza, so it's safe to re-assign the value on subsequent passes. This is fa63c8fIncludes a minor refactor to make it clear where we're accessing dstate. The field name
Deployment.TaskGroups
contains a map ofDeploymentState
, which makes it a little harder to follow state updates when combined with inconsistent naming conventions, particularly when we also have the state store or actualTaskGroup
s in scope. Change all uses todstate
so as not to be confused with actual TaskGroups. This is a separate commit 7552fff.