cert-manager / website

Source code for the cert-manager.io website, including project documentation

Home Page:https://cert-manager.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Describe cert-manager feature policy

irbekrm opened this issue · comments

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

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