graduate kube-scheduler ComponentConfig to GA #3315
Conversation
Signed-off-by: kerthcet <kerthcet@gmail.com>
k8s-ci-robot
added
the
cncf-cla: yes
|
/sig scheduling |
k8s-ci-robot
added
size/S
| The fourth iteration, `kubescheduler.config.k8s.io/v1`, includes the following changes: | ||
| - Remove `v1beta2` |
There was a problem hiding this comment.
This should be moved below L110.
Signed-off-by: kerthcet <kerthcet@gmail.com>
| @@ -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. | |||
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Signed-off-by: kerthcet <kerthcet@gmail.com>
keps/sig-scheduling/785-scheduler-component-config-api/README.md
Outdated
Show resolved
Hide resolved
keps/sig-scheduling/785-scheduler-component-config-api/README.md
Outdated
Show resolved
Hide resolved
Signed-off-by: kerthcet <kerthcet@gmail.com>
|
/approve /cc @alculquicondor |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Huang-Wei, kerthcet The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
k8s-ci-robot
added
the
lgtm
|
Oh my bad. I shouldn't have lgtmed because there were files requiring updates. Please work on those and get the approvers to look at them |
Signed-off-by: kerthcet kerthcet@gmail.com