ceph / ceph-csi-operator

Kubernetes operator for managing the CephCSI plugins
Apache License 2.0
13 stars 13 forks source link

CRD apiVersion for stable features running in production should be v1beta1 #43

Open travisn opened 2 months ago

travisn commented 2 months ago

Describe the feature you'd like to have

The CSI operator CRDs should be v1 instead of v1alpha1 when we expect it to be running in production.

The conversation was started in the csi operator design doc here, but it was marked resolved after some offline conversation without documenting the reasoning. Let's discuss openly on the expectation for v1.

Who is the end user and what is the use case where this feature will be valuable?

Users look at CRD stability for a clue if it is production ready. We are taking a stable CSI driver and moving the settings to a stable CSI operator where we expect it to quickly be used in production. Production users will expect a stable version, even though it's new.

Many users may not care about the api version as long as we claim to support it, but some users will look at an alpha version and refuse to run it in production. For Rook upstream I consider it a blocker to use alpha CRDs in production deployments.

If we are anyway supporting it in production, we have to provide full support for all of our customers, for all new and upgraded clusters, with full feature parity for all customized settings. To me, that is the definition of v1, not alpha. Why not just ship with v1 now? Then we don’t have to worry about conversion to v1 later. As suggested, we expect stability from the start if we are putting it in production.

And if we are supporting alpha in production, let's define the blocking criteria for moving it to v1.

travisn commented 2 months ago

After some offline discussion, the blocker for declaring stable upstream would be to declare at least v1beta1.