scheduler: stop clearing NominatedNodeName on all cases #132439
Conversation
|
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/test pull-kubernetes-unit |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: utam0k The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/test pull-kubernetes-e2e-kind |
Signed-off-by: utam0k <[email protected]>
|
Is this relevant to #132443? |
|
Changelog suggestion -The scheduler no longer clears the NominatedNodeName field for pods. External components (like Cluster Autoscaler and Karpenter) are responsible for managing this field when needed.
+The scheduler no longer clears the `nominatedNodeName` field for Pods. External components (such as Cluster Autoscaler and Karpenter) are responsible for managing this field when needed.However, see #132443 (comment) We should align the two changelog entries. |
Yes, it is. I've updated the release note. |
| @@ -365,7 +363,7 @@ func (sched *Scheduler) handleBindingCycleError( | |||
| } | |||
| } | |||
|
|
|||
| sched.FailureHandler(ctx, fwk, podInfo, status, clearNominatedNode, start) | |||
| sched.FailureHandler(ctx, fwk, podInfo, status, nil, start) | |||
There was a problem hiding this comment.
Should we make these changes under a feature flag or we are okay with leaving them unguarded?
@sanposhiho What is the strategy for using the feature gate in this KEP?
There was a problem hiding this comment.
Yes, we should guard a new logic and we (including my PRs) forgot doing that 😅 (ref).
We already talked about it in DM and will update the PRs.
What type of PR is this?
/kind feature
/sig scheduling
/cc sanposhiho
What this PR does / why we need it:
ref: #132384
Which issue(s) this PR is related to:
Fixes #132384
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: