-
Notifications
You must be signed in to change notification settings - Fork 39.7k
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
dra scheduler: fix incorrect tracking of claim candidates for reallocation #122415
dra scheduler: fix incorrect tracking of claim candidates for reallocation #122415
Conversation
…ation When dealing with unschedulable pods, the intent was to deallocate only claims which are allocated and use delayed allocation. That if check wasn't handled correctly, causing also claims with immediate allocation to be considered as candidates. Found during code reading, probably has never occurred in practice yet.
/assign @bart0sh |
@@ -754,7 +754,7 @@ func (pl *dynamicResources) Filter(ctx context.Context, cs *framework.CycleState | |||
// would just get allocated again for a random node, | |||
// which is unlikely to help the pod. | |||
if claim.Spec.AllocationMode == resourcev1alpha2.AllocationModeWaitForFirstConsumer { | |||
state.unavailableClaims.Insert(unavailableClaims...) | |||
state.unavailableClaims.Insert(index) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to cover this with a unit or e2e tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a test which exercises deallocation, just not in a way that mattered here.
As this is such a subtle difference, I am not sure how to write a test that covers this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One test also makes sense to me.
/approve
/triage accepted |
/lgtm |
LGTM label has been added. Git tree hash: 8c36b56c9cfaf99123538e63053cdd0c8ce0a413
|
/assign @kerthcet For approval. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kerthcet, pohly The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
Related to #122270 |
What type of PR is this?
/kind bug
What this PR does / why we need it:
When dealing with unschedulable pods, the intent was to deallocate only claims which are allocated and use delayed allocation. That if check wasn't handled correctly, causing also claims with immediate allocation to be considered as candidates.
Special notes for your reviewer:
Found during code reading, probably has never occurred in practice yet.
Does this PR introduce a user-facing change?