-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Enable beta features by default #6732
Conversation
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/assign |
/hold |
acd2a68
to
d857574
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
error was:
test pass locally-- if retesting passes I will file an issue |
This happened because our prow config hard-codes the file "test/e2e-tests-kind-prow.env" which I attempted to rename. reverted. |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
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.
Thanks Lee!
shall we also change to beta at prow.env for testing the defaults deployed?
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.
Thanks Lee!
shall we also change to beta at prow.env for testing the defaults deployed?
I think we already have 3 e2e configurations for prow, one for each feature gate, so I'm not sure we need changes. The file e2e-tests-kind.env doesn't seem to be used anywhere in our prow config. |
When users decide to upgrade to v1 APIs, they may not be aware they are using beta features. If they are using the default value ("stable") of "enable-api-fields", any beta features they're using will work in beta APIs, but break when when move to v1 APIs. This commit changes the default value of "enable-api-fields" to "beta", to ensure beta features continue to work by default when users change API versions. Independently, we plan to decouple API versioning from feature versioning. This commit is not backwards compatible.
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JeromeJu, vdemeester 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 |
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.
Thanks for this.
Would it make sense to deprecate the beta
default value right away (it can be in a different PR) and setting a date by when we will switch back to stable
as default?
As discussed, I'd love to see the feature flag decoupled from the API version in future.
/lgtm
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.
Thanks for this.
Would it make sense to deprecate the beta
default value right away (it can be in a different PR) and setting a date by when we will switch back to stable
as default?
As discussed, I'd love to see the feature flag decoupled from the API version in future.
/lgtm
I think this is worth a separate discussion. We'd need to find some way to resolve the issue referenced when using "stable" as the default. I also think "beta" is a reasonable default anyway: k8s enables beta features by default. My preferred solution is per-feature flags.
👍 , this is causing a lot of problems tbh |
When users decide to upgrade to v1 APIs, they may not be aware they are using beta features. If they are using the default value ("stable") of "enable-api-fields", any beta features they're using will work in beta APIs, but break when when move to v1 APIs.
This commit changes the default value of "enable-api-fields" to "beta", to ensure beta features continue to work by default when users change API versions. Independently, we plan to decouple API versioning from feature versioning (#6592).
This commit will also help avoid breakages when swapping our storage version to v1 due to the issue described here.
This commit is not backwards compatible.
Related: #6616
/kind misc
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
/kind <type>
. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes