Skip to content
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

Conversation

draveness
Copy link
Contributor

@draveness draveness commented Oct 24, 2019

/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?:

Deprecate Node.Spec.Unschedulable, TaintNodesByCondition is used to replace this feature. The field will be removed in 1.21

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:


@k8s-ci-robot k8s-ci-robot added kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. sig/node Categorizes an issue or PR as relevant to SIG Node. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels Oct 24, 2019
@draveness
Copy link
Contributor Author

/priority important-soon

@k8s-ci-robot k8s-ci-robot added priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API sig/apps Categorizes an issue or PR as relevant to SIG Apps. and removed needs-priority Indicates a PR lacks a `priority/foo` label and requires one. labels Oct 24, 2019
@fejta-bot
Copy link

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.

@draveness draveness force-pushed the feature/deprecate-node-unscheduable branch from 4e761fb to 3e9f72a Compare October 24, 2019 03:33
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: draveness
To complete the pull request process, please assign liggitt
You can assign the PR to them by writing /assign @liggitt in a comment when ready.

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Copy link
Contributor

@mattjmcnaughton mattjmcnaughton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/assign liggitt
cc @bsalamat

/lgtm

Defer to @bsalamat on if this is the proper time, but from everything I read in the issue, seems like this is appropriate.

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 24, 2019
@mattjmcnaughton
Copy link
Contributor

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!

@draveness
Copy link
Contributor Author

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

@liggitt
Copy link
Member

liggitt commented Oct 24, 2019

The field will be removed in 1.21

The field will not be removed in 1.21. Fields can only be removed by incrementing the API version:

Rule #1: API elements may only be removed by incrementing the version of the API group.

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?)

Rule #2: API objects must be able to round-trip between API versions in a given release without information loss

@@ -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.
Copy link
Member

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

Copy link
Contributor Author

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?

Copy link
Contributor Author

@draveness draveness Oct 24, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ref: #61877

Copy link
Member

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

Copy link
Contributor Author

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

@k8s-ci-robot
Copy link
Contributor

@draveness: Closed this PR.

In response to this:

OK, I'll close this PR since we can't do this for now.

/close

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.

@draveness
Copy link
Contributor Author

The field will be removed in 1.21

The field will not be removed in 1.21. Fields can only be removed by incrementing the API version:

Rule #1: API elements may only be removed by incrementing the version of the API group.

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?)

Rule #2: API objects must be able to round-trip between API versions in a given release without information loss

Can we add an annotation to the Node v2alpha1 API and deprecate the annotation when the version bumped to v2beta1?

@draveness draveness deleted the feature/deprecate-node-unscheduable branch October 24, 2019 15:23
@liggitt
Copy link
Member

liggitt commented Oct 24, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. lgtm "Looks good to me", indicates that a PR is ready to be merged. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/apps Categorizes an issue or PR as relevant to SIG Apps. sig/node Categorizes an issue or PR as relevant to SIG Node. sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants