KEP-3136: beta apis off by default

[deads2k]

• One-line PR description: New beta APIs will not be enabled in clusters by default. Existing beta APIs and new versions of existing beta APIs, will continue to be enabled by default.

• Issue link: Beta APIs Are Off by Default #3136

• Other comments:

/assign @liggitt @derekwaynecarr @johnbelamaric @dims
/cc @wojtek-t

[wojtek-t]

Thanks a lot for opening this David!
As dicussed offline - I'm 100% supportive for it, just added some minor claryifying questions.

[aojea]

+1 on the idea, but some concerns about the timing.
A change like this has a considerable impact and at least one release in advance to start announcing and communicating it will be better
#3137 (comment)

[liggitt]

A change like this has a considerable impact and at least one release in advance to start announcing and communicating it will be better

Since this is not proposing a change to any existing beta APIs, I don't think the impact is that considerable. Every new beta API enabled by default represents future pain for users that start depending on it without realizing it has a relatively short lifecycle. I think this should go into effect for 1.24+.

[liggitt]

lgtm

[apelisse]

I'm a little surprised by that KEP.

I'm typically ranting that alpha features never receive any testing, interest, adoption, feedback until they become beta because they're disabled, basically making these alpha versions mostly useless (IMO, you seem to have numbers that disagree with my gut feeling). The change you're suggesting means that untested features might become GA instantly for many clusters.

Building things on top of Beta APIs is probably the best way to test them and give feedback, see if they're useful.

[sftim]

A few thoughts / suggestions.

[deads2k]

clarified a few more bits of text for comments.

[dims]

we just have a few days to get this in ... @deads2k can you please mark conversations that are resolved, so we can figure out what's left to tackle?

[deads2k]

we just have a few days to get this in ... @deads2k can you please mark conversations that are resolved, so we can figure out what's left to tackle?

I think the remaining concern is #3137 (comment). https://github.com/kubernetes/enhancements/pull/3137/files#diff-0ad9f743dbfdf3932906414acf0a79e074af723ad2ffb8e0dab3429f0b664beeR261 got added to mitigate it.

[sftim]

If this KEP merges, the website might need some changes (including Go templating) to help people documenting future features explain which APIs are beta-and-on-by-default, compared to other APIs etc that are beta-and-opt-in.

Remember to check in with the release docs team for v1.24 about that.

[sftim]

I also recommend revising / expanding the feature state shortcode with a parameter to indicate whether or not the feature is enabled by default.

[wojtek-t]

IIUC, this mostly means "test for per-APi enablement"? Worth making more explicit?

[wojtek-t]

/approve PRR

[Initially that sounded strange, but given this actually will trigger some (small but still) changes to PRR, this actually seems more related now :) ]

[dims]

/approve

/hold for any other reviewers you may need @deads2k

[liggitt]

/approve
for me as well

looks like @johnbelamaric acked at #3137 (comment)

ack from @derekwaynecarr outstanding?

[derekwaynecarr]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, derekwaynecarr, dims, liggitt, wojtek-t

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/prod-readiness/OWNERS [deads2k,wojtek-t]
• keps/sig-architecture/OWNERS [derekwaynecarr,dims]

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

[wojtek-t]

Cancelling hold with approvals from all SIG Arch leads.

[wojtek-t]

/hold cancel

[wojtek-t]

/lgtm