Skip to content
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

Describe cert-manager feature policy #1125

Open
irbekrm opened this issue Dec 5, 2022 · 1 comment
Open

Describe cert-manager feature policy #1125

irbekrm opened this issue Dec 5, 2022 · 1 comment

Comments

@irbekrm
Copy link
Contributor

irbekrm commented Dec 5, 2022

At the moment all our features are in alpha.

We have also marked beta features as off by default:

--feature-gates mapStringBool                         A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
                                                            AdditionalCertificateOutputFormats=true|false (ALPHA - default=false)
                                                            AllAlpha=true|false (ALPHA - default=false)
                                                            AllBeta=true|false (BETA - default=false)

This is not defined in cert-manager codebase- it seems to come from component-base as we use that library to define our feature gates.
Meanwhile upstream Kubernetes have beta feature gates on by default

Should we follow upstream and have beta features on by default?

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/feature-gates.md

https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#feature-stages

@irbekrm
Copy link
Contributor Author

irbekrm commented Jan 11, 2023

Additional questions:

  • What is the value of the beta feature gates if they are off by default? Do we make a different promise in regards to not breaking things in beta, such as an X number of releases before a beta feature gets removed or a breaking change is implemented?
  • some of the features require a feature flag for both controller and webhook. Should we explicitly define what version skew is supported for the two? See also https://kubernetes.slack.com/archives/CDEQJ0Q8M/p1673450064356839?thread_ts=1671711180.206949&cid=CDEQJ0Q8M
  • can we define any generic graduation criteria, i.e after X number of releases a feature could be promoted? Is it reasonable to require user feedback to graduate a feature alpha -> beta and how do we get that/what setups are sufficient?

Most features of the alpha features will probably require looking at individually to define what needs to be done to graduate them/whether there are any reported issues etc.

Here is an example graduation criteria write-up for a specific feature in upstream https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1693-warnings#graduation-criteria

Interesting upstream discussion about feature policy https://docs.google.com/document/d/1roVAHyF7eWZAccmCKw7MXYUNgx4BCDSXF2IMS8h10oY/edit?usp=sharing&resourcekey=0-x6Tw2qz1SpCIPhbec6Qa2A
Outlines a few issues upstream:

  • users don't test alpha and treat beta as GA
  • lack of consistency for rollbacks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant