Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
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
KEP-3136: beta apis off by default #3137
KEP-3136: beta apis off by default #3137
Changes from 4 commits
c1323bee55c925c99f10431b12d8ead3b89f73839cFile filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC, this mostly means "test for per-APi enablement"? Worth making more explicit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also recommend revising / expanding the feature state shortcode with a parameter to indicate whether or not the feature is enabled by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An alternative - or maybe more accurately a follow up - could be something like the "API lenses" idea @thockin proposed a couple years ago here: https://docs.google.com/document/d/1bjyu7ksEM2sNpIyA625zj8XHt_5xtaX_z2EtvA7_fLQ/edit#heading=h.5m3e1uuqb7dd
That proposal is mostly talking about adding/modifying fields within an API. However, a similar concept can be applied to whole APIs. For example, this could amount to a "hidden" setting for beta APIs: the API is enabled, but in order to use it, you need to add a special HTTP header. This would avoid the inadvertent "just copy and paste this manifest from the internet" type of spread of APIs. That is, our current method of designated use of a beta API - just slightly different value in a yaml file - is too easy and accessible. The "special header" (or some other mechanism) makes it a more explicit choice (at least until some big provider just sets up all their tooling with that enabled always...).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's exactly what would happen :-/
opt-in things like that are super hard to propagate through pipelines that compose/wrap other tools or manifests, so things designed to handle generic manifests opt into every possible option to work with as many sources as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main point here is that this provides a mechanism that:
It's somewhat of a middle ground, recognizing that in a shared cluster environment, a specific team may want to rely on a beta feature, but we do not want to expose other users of that cluster to inadvertent risk of creating tech debt.
My proposal would be to implement this KEP - i.e., stop the bleeding/creation of new debt for our users - and then follow up as quickly as possible with something like this that shifts the beta API consumption decision to end users that are well-aware of what they are doing (and only if allowed by the admin, of course).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liggitt, sorry didn't see your comment before I made my second comment. It may be that that would happen. But that would be the providers choice, not the projects choice. That argument also can be used to say "this KEP is useless, people will just explicitly set them to 'on' always".
As I see it, as a project have a couple responsibilities:
I do think the we can do more for 2). I think some proposal like this may be useful in that regard. But that's subject to debate. There are also other ways too help. For example, we can build (via enhancements process or contribex, perhaps), programs to make it easy to recruit and collect feedback from beta testers - a stable set of companies / teams / individuals that have said they are willing to sign up for betas, perhaps. And tooling to provide feedback channels that users can access to review beta features. Even clusters we can stand up, enabled for beta, for them to use (beware the crypto miner hackers :( ).
For those folks that are worried about a loss in feedback for features - it would be good to start to put together some ideas in this area.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really have to do more? I'm assuming that every feature we're building (especially when we're talking about full APIs - because that's what we're talking here), we are not building "in the air". We have real-life usecases and requests for them. They are backed by real users who want to use them. So they are the ones who should be able to provide feedback, and I think as devs we are either exposed to those users or we work in companies who are exposed to them (which means we're also indirectly exposed to them and can probably gather this feedback).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, good points. however some folks are concerned about the amount of feedback we'll get. rather than have every SIG re-invent the mechanisms, we may be able to help. but I agree it's not clear any help is needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fair, but a lot of the time, probably specifically for API machinery, we create features that will enable people to build "stuff", and they don't know they can build these "stuff" until they try it out. We're building features for way more people than our mere customer base, and we see companies thrive by using our features in creative ways.
Also related to that, a lot of the time, teams can't really rely on a feature until it's enabled on all supported cluster versions. The release process being what it is, that's already a very long time. Turning beta features off will only make that step longer (and more risky). I think this change generally increases the GTM time and risk, two metrics that people are generally trying to decrease.