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.
Describe the feature you'd like to have
The CSI operator CRDs should be
v1
instead ofv1alpha1
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.