Skip to content

graduate kube-scheduler ComponentConfig to GA #3315

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.

Sign up for GitHub

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

Merged
merged 4 commits into from
Jun 6, 2022
Merged

graduate kube-scheduler ComponentConfig to GA #3315

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
b3b2ce8
Feat: graduate kube-scheduler component config to GA
kerthcet May 18, 2022
4725039
Move the doc to the right place
kerthcet May 19, 2022
acda488
Mark v2beta2 as deprecated instead of removing
kerthcet Jun 1, 2022
5c920af
resolve format problems
kerthcet Jun 1, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 9 additions & 1 deletion keps/sig-scheduling/785-scheduler-component-config-api/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,8 @@

The kube-scheduler configuration API `kubescheduler.config.k8s.io` was in alpha
for several releases. We graduated it to beta in 1.19 as `v1beta1`. We introduced
`v1beta2` and `v1beta3` in 1.22 and 1.23 respectively.
`v1beta2` and `v1beta3` in 1.22 and 1.23 respectively. We'd like to graduate it
to GA in `v1.25` and remove the support for `v1beta2` at the same time.
Copy link
Contributor

@pohly pohly May 20, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

I believe beta APIs must be supported for one release in parallel to their replacement, to give users time to migrate. That means in v1.25 you mark v1beta as deprecated, then remove it in v1.26.

I think that matches the "after their announced deprecation" when not counting the release in which that gets announced. If you want to remove sooner, ask an API reviewer for clarification. EDIT: the core beta API example clarifies that "for no less than" includes the release in which the deprecation gets announced. There it is three releases (deprecation in X+5, removal in X+8), but the wording is the same.

A related question: when adding a new alpha-level configuration field, will that then get added to all supported versions with a feature gate check (this is how core Kubernetes APIs get extended) or do you prefer to add a v1alpha3 as a true superset of the v1 API?

Copy link
Member Author

Choose a reason for hiding this comment

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

I believe beta APIs must be supported for one release in parallel to their replacement, to give users time to migrate. That means in v1.25 you mark v1beta as deprecated, then remove it in v1.26.

I think that matches the "after their announced deprecation" when not counting the release in which that gets announced. If you want to remove sooner, ask an API reviewer for clarification. EDIT: the core beta API example clarifies that "for no less than" includes the release in which the deprecation gets announced. There it is three releases (deprecation in X+5, removal in X+8), but the wording is the same.

From scheduling side, we came to a consensus before as we don't want to maintain three CC versions, so when we upgrade CC to v1beta3, we dropped the support of v1beta1. But as you said, it's important to not breaking existing users, so I'd like to mark v1beta2 deprecated in v1.25, and remove it in v1.26(theoretically in v1.28), any thoughts?

A related question: when adding a new alpha-level configuration field, will that then get added to all supported versions with a feature gate check (this is how core Kubernetes APIs get extended) or do you prefer to add a v1alpha3 as a true superset of the v1 API?

Good question, considering it's an experimental feature, feature-gate might be a better choice for most of the time. Version upgrades should not be too frequently, or it will increase the burden of end-users.

Copy link
Member

Choose a reason for hiding this comment

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

Feature-gating experimental things in config files is reasonable. The goal is to prevent accidental use of an unstable thing, thinking it is a stable thing.

Config file APIs don't have the same round-tripping requirements as REST APIs (not every field in v1beta3 has to be readable via v1beta2, for example). I'd generally recommend just adding new fields to the latest config file version, as an incentive to update to newer config versions.

Copy link
Member

Choose a reason for hiding this comment

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

I'm also inclined to only add new fields to the latest CC version, b/c if an end-user is not aware of the new feature, using an old but supported CC version would preserve its old behavior, which is fine; while if the end-user wants to use the new feature, turning to latest CC version makes more sense.

Copy link
Member

Choose a reason for hiding this comment

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

I'd like to mark v1beta2 deprecated in v1.25, and remove it in v1.26(theoretically in v1.28), any thoughts?

SGTM. Let's keep it for another release.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done, PTAL @Huang-Wei


## Motivation

Expand Down Expand Up @@ -105,6 +106,9 @@ The third iteration, `kubescheduler.config.k8s.io/v1beta3`, includes the followi
- Remove `v1beta1`
- Remove the legacy [policy config API](https://kubernetes.io/docs/reference/scheduling/policies/)

The fourth iteration, `kubescheduler.config.k8s.io/v1`, includes the following changes:
- Remove `v1beta2`
Copy link
Member

Choose a reason for hiding this comment

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

This should be moved below L110.

Copy link
Member Author

Choose a reason for hiding this comment

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

done


The main reason is that some plugins have "default" behavior without needing user inputs, whereas the above plugins are
about user preferences, so should have more influence while making scheduling decisions.
More information on the discussion can be found [here](https://github.com/kubernetes/kubernetes/issues/88174).
Expand Down Expand Up @@ -219,6 +223,9 @@ N/A
- No changes to plugins enabled by default. Only their weights would change.
- Remove `v1beta1`.

When `v1` gets introduced:
- Remove `v1beta2`.

### Monitoring requirements

* **How can an operator determine if the feature is in use by workloads?**
Expand Down Expand Up @@ -302,3 +309,4 @@ N/A
- 2021-07-08: Introducing `v1beta2`.
- 2021-08-06: Introducing `v1beta3`.
- 2021-09-01: Remove `v1beta1` and the legacy policy config API.
- 2022-05-18: Introducing `v1` and remove `v1beta2`.