-
Notifications
You must be signed in to change notification settings - Fork 39.4k
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
feat: mark node unschedulable as deprecated #84266
feat: mark node unschedulable as deprecated #84266
Conversation
/priority important-soon |
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. |
4e761fb
to
3e9f72a
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: draveness 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 |
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.
Oh one small note... can you update your PR so it doesn't indicate that is "Fixes" (and thus closes) the issue? I don't think this PR address the third step, which is updating the documentation. Thanks! |
done /assign @liggitt |
The field will not be removed in 1.21. Fields can only be removed by incrementing the API version:
It could theoretically be removed in a hypothetical v2 Node API object, as long as data from v1 could round-trip through a v2 object somehow (potentially via an annotation?)
|
@@ -3683,7 +3683,9 @@ type NodeSpec struct { | |||
// +optional | |||
ProviderID string | |||
|
|||
// Unschedulable controls node schedulability of new pods. By default node is schedulable. | |||
// Deprecated. Unschedulable controls node schedulability of new pods. By default, node is schedulable. | |||
// Remove field after 1.21. |
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.
we do not remove fields from a given version, see links to the deprecation policy
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.
So, we can't deprecate the API unless we have a v2. I noticed the ExternalID
was marked as deprecated and prefixed with DoNotUse
, can we do the same thing to Unschedulable
field here?
// Deprecated. Not all kubelets will set this field. Remove field after 1.13.
// see: https://issues.k8s.io/61966
// +optional
DoNotUseExternalID string `json:"externalID,omitempty" protobuf:"bytes,2,opt,name=externalID"`
BTW: Do we have plans or documents on when we could start with a new major version of API?
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.
ref: #61877
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.
So, we can't deprecate the API unless we have a v2.
Correct
I noticed the ExternalID was marked as deprecated and prefixed with DoNotUse, can we do the same thing to Unschedulable field here?
The use case for ExternalID was much more narrow and had a single writer (the node). I would not change the name of the Unschedulable field.
Do we have plans or documents on when we could start with a new major version of API?
Not currently
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.
OK, I'll close this PR since we can't do this for now.
/close
@draveness: Closed this PR. In response to this:
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/test-infra repository. |
Can we add an annotation to the Node v2alpha1 API and deprecate the annotation when the version bumped to v2beta1? |
that is one possible approach, yes |
/kind cleanup
/sig node
/sig scheduling
What this PR does / why we need it:
TaintNodeByCondition has replaced the existing node condition. With this feature node conditions that affect the feasibility of nodes are reflected as taints on nodes. This feature is promoted to GA in #82703, we could announce the depracation of it now, and remove it after 4 releases (1.21).
Which issue(s) this PR fixes:
ref #69010
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: