KEP-5241: Beta Feature Gate Promotion Requirements #5242
Conversation
deads2k
commented
Apr 14, 2025
deads2k
commented
- One-line PR description: Features gates must include all functional, security, and testing requirements along with resolving all issues and gaps identified prior to being enabled by default.
- Issue link: Beta Feature Gate Promotion Requirements #5241
- Other comments:
k8s-ci-robot
added
the
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: deads2k 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 |
k8s-ci-robot
added
kind/kep
deads2k
changed the title
deads2k
force-pushed
the
production-quality
branch
from
d15bc9d to
3b33ffc
Compare
|
@deads2k: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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-sigs/prow repository. I understand the commands that are listed here. |
| ## Proposal | ||
|
|
||
| Kubernetes feature gates have three levels: GA, Beta, and Alpha. | ||
| 1. GA means that a feature gate is unconditionally enabled in all production kubernetes clusters and |
There was a problem hiding this comment.
we have two levels here GA, and GA locked by default, without locked by default it can be disabled, right?
| 2. Beta means that a feature gate is usually enabled in all production Kubernetes clusters by default | ||
| and that feature can be disabled. | ||
| Exceptions exist for entirely new APIs and some node features, but this broadly the case. |
There was a problem hiding this comment.
this tends to confuse readers and new developers not familiar with the the duality of API version v1alpha1, v1beta1, v1 / feature gate alpha,beta, GA and the coupling of both lifecycles. Since the restriction about beta apis disabled by default, that makes feature gates that are beta and depende on api beta versions disabled by default.
Beta features non dependent on beta APIs are usually enabled by default ??? I do not know well how to express this conundrum
|
|
||
| Phasing in larger features over time can be done by bringing separate feature gates through alpha, beta, and GA. | ||
| Each feature gate needs to meet the beta and GA criteria for completeness, functional, security, and testing. | ||
| After meeting hte criteria for enabled by default, and at the sig's discretion, the new feature gate could be |
There was a problem hiding this comment.
| After meeting hte criteria for enabled by default, and at the sig's discretion, the new feature gate could be | |
| After meeting the criteria for enabled by default, and at the SIG's discretion, the new feature gate could be |
| in v1.Y broke under the same feature gate. | ||
|
|
||
| #### Who will make sure that new KEPs follow the promotion rules? | ||
| We'll adjust the KEP template to indicate the allowed criteria, so authors should notice. |
There was a problem hiding this comment.
Only for new features. Authors of some existing KEP only notice if they actively sync with the KEP template (rarely done) or we announce this KEP here widely.
| To balance these concerns, we are changing how we evaluate Beta and GA stability criteria. | ||
| The only valid GA criteria are “all issues and gaps identified as feedback during beta are resolved”. | ||
| Promotion from Beta to GA must be zero-diff for the release. | ||
| This means that Beta criteria must include all functional, security, and testing requirements along |
There was a problem hiding this comment.
I think we should also add monitoring and I know that @lmktfy has mentioned satisfactory documentation in beta before we promote to GA.
kikisdeliveryservice
added
the
kind/template
