KEP-5241: Beta Feature Gate Promotion Requirements

[deads2k]

• 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:

[pohly]

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.

[BenTheElder]

There's another topic about that in SIG Arch today. bit.ly/kep-versioning_phase1

[johnbelamaric]

Suggested change

	4Alpha means that a feature gate is disabled in all production Kubernetes clusters by default and
	4. Alpha means that a feature gate is disabled in all production Kubernetes clusters by default and

[johnbelamaric]

/approve

[dims]

/approve

thanks for writing this up @deads2k

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, dims, johnbelamaric

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:

• keps/OWNERS [dims,johnbelamaric]
• keps/prod-readiness/OWNERS [deads2k,johnbelamaric]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[derekwaynecarr]

i think this may need a tweak on the template readme to call out monitoring/instrumentation.

[derekwaynecarr]

unless i am mistaken, the summary adds 'monitoring' requirements, but its not highlighted earlier. i do not see it called out in beta or GA explicitly unless i missed it. relevant instrumentation is important, but i am not sure if addition of a metric observed during a beta phase extends the beta phase, blocks promotion to GA phase, or what. wdyt?

[derekwaynecarr]

if this is the intent, recommend calling out instrumentation in the kep template under beta, and note that any new instrumentation would extend the beta another release. i am not sure if this introduces a negative incentive in some cases, but we would have to see how that plays out. in some cases, correlating a metric to a single feature may not always be clear if it had cross-cutting value.

[johnbelamaric]

I don't think adding a new metric should "automatically" require a second beta, for these reasons:

1. Metrics themselves have independent alpha/beta/stable guarantees which are not generally in sync with the feature they monitor.
2. There is space between metrics that are "necessary to support the feature in production" and those that are "useful to have".

The evaluation of whether the metrics that are necessary to support a feature in production are all there is a GA criteria. This KEP update is saying that "we should require those to be available in beta", which I think is a good thing.

Even if we screw that up, and miss something that is critical in beta, adding it before GA should be sufficient. I don't think we want to say "all bugs/missing metrics must be fixed and then we must do another beta before GA".

[deads2k]

I've updated "zero-diff" to "no significant change" to try to better reflect our intent.