[KEP-3521] Part 1: New Pod API .spec.schedulingGates#113274
[KEP-3521] Part 1: New Pod API .spec.schedulingGates#113274k8s-ci-robot merged 2 commits intokubernetes:masterfrom
Conversation
|
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
f3b90e4 to
d14305f
Compare
|
cc @ahg-g There are 2 PRs upcoming: scheduler implementation and integration/e2e tests. |
There was a problem hiding this comment.
Yeah, I asked for it for future proofing.
There was a problem hiding this comment.
I would use blocked instead of pause.
There was a problem hiding this comment.
Agree. Or SchedulingGated (it should be rare enough that calling it gated will help people find the field.
There was a problem hiding this comment.
Updated to schedulingGated which is more close to the new field name.
There was a problem hiding this comment.
It's b/c this "reason" is used in the output of k get pod, and thusPodReasonWaitingForGates which holds the literal "WaitingForGates" loses the context - a word describing that it's scheduling gated would be more self-descriptive.
|
/assign @smarterclayton |
|
/label api-review |
There was a problem hiding this comment.
This should really be in validation - a regular user can patch a pod and set spec.nodeName without binding.
There was a problem hiding this comment.
ah, update's validation has already been covered. Here it's an additional validation for pod creation - prevent user creating a pod directly with nodeName and non-empty scheduling gates.
There was a problem hiding this comment.
But here pod.Spec.NodeName won't be empty, we returned in the above. I think we should move this ahead.
There was a problem hiding this comment.
not quite. L223~L225 is checking whether it's updating nodeName X to Y.
There was a problem hiding this comment.
prevent user creating a pod directly with nodeName and non-empty scheduling gates
I see, misunderstood the words here. Great catch.
Thanks. Tracked in #113608 |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Huang-Wei, smarterclayton The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
- New API field .spec.schedulingGates
- Validation and drop disabled fields
- Disallow binding a Pod carrying non-nil schedulingGates
- Disallow creating a Pod with non-nil nodeName and non-nil schedulingGates
- Adds a {type:PodScheduled, reason:WaitingForGates} condition if necessary
- New literal SchedulingGated in the STATUS column of `k get pod`
|
/lgtm |
|
/hold |
|
/unhold |
|
/hold cancel |
A bit late to the game, but this looks great - thx! |
|
/remove-sig api-machinery |
|
/triage accepted |
|
@Huang-Wei @smarterclayton there is a typo the PR comment that made it into the CHANGELOG. From the user-facing change section (that is scraped by the changelog generator), |
What type of PR is this?
/kind feature
/sig scheduling
What this PR does / why we need it:
This is the first part of implementing KEP 3521, including:
{type:PodScheduled, reason:SchedulingGated}condition upon pod creationSchedulingGatedin the STATUS column ofk get podWhich issue(s) this PR fixes:
Part of #113269
Special notes for your reviewer:
Get best review UX commit by commit.
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: