-
Notifications
You must be signed in to change notification settings - Fork 373
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
Alpha Beta GA designation for new capabilities #355
Comments
Proposal from @jieyu -- maintain multiple proto files: GA, alpha.
|
I was thinking that we should have a csi-extension repo that possibly vendors-in the main CSI spec and then adds some extension on top of it. Some projects may choose to implement csi-extension spec and some other may adopt stable APIs. The tricky thing perhaps will be most COs will only want to adopt CSI stable/main and even if a driver has support for csi-extension spec it may not be used immediately if CO does not support it. Once changes in csi-extension become stable, they can be moved off to main repo. |
Simpler alternative from @julian-hj during meeting:
What about RPCs?
What about wild and crazy ideas?
|
Is this about the API incompatibility in the Go bindings between CSI 1.0.0 and 1.1.0? The problem is this: a CSI plugin that compiles with the Go bindings for 1.0.0 will not compile after updating to 1.1.0 unless the new gRPC calls are added to the source code of the plugin, because otherwise its implementation no longer matches the extended interface definition. I consider this a violation of the semver contract that defines minor version bumps as "add functionality in a backwards-compatible manner" - its not backwards-compatible if users of the API have to be updated. I'm not sure whether there is a good solution just with gRPC generated code. But this could work:
|
Thanks for your comments @pohly. I know that when I think of CSI spec versioning and backward compatibility, I normally don't ask myself "is the generated Go code honoring the semantic versioning contract?" gRPC supports so many languages, and there's no spec for what gRPC compilers should generate. Consider that it's possible to write a gRPC compiler for Go that would not generate I think the best that we can do w/ respect to semver guarantees is aim to be backward compatible "on the wire". Meaning that a CSI 1.0 CO should be able to interact successfully w/ a CSI 1.1 plugin, and vice-versa. Your suggestion of a "null" implementation sounds like it would work, but I'm not 100% convinced that we should add it to this project. In the past we've drawn the line for per-language, library code in this repo at "it must be auto-generated from the spec". AFAIK the default protoc+grpc tooling doesn't have an option to generate null/adapter Go implementations of the Go interfaces - and so it would fall outside the scope as we've previously discussed. All that said, it's also come up several times that various members of the community are interested in common libraries for CSI, above and beyond what's included in this repo. Null/adapter implementations (of each CSI service) sound like a good fit for something like that. |
Fair enough. I just wanted to know whether this had been considered.
I'm worried that such additional common libraries will not gain critical mass and/or enough long-term support unless some existing group does them. Has it been considered to host such work in the github.com/container-storage-interface organization, i.e. owned by the same people who are also currently managing the spec? |
Based on the "alpha API" discussion in the most recent CSI community sync I've drafted some mock ups of some fake experimental APIs so that we can all see how things might look: PTAL #365 |
Problem
Now that CSI is 1.0, we can no longer make backwards compatibility breaking changes. But we want to continue to add new functionality to CSI, and it is almost impossible to propose an API and have it be "perfect" in its initial release (which is why CSI remained in 0.x for a year).
Goal
We should define a process for introducing new official APIs as alpha then promote to beta and then GA.
Proposal
This can be as simple as a comment on a capability designating it alpha, beta, or GA. The tricky part is how alpha APIs can change without breaking clients. So we may need to say that fields and methods can be renamed/deprecated but never removed. Alpha features can be renamed or deprecated in any release. Beta features can be renamed or deprecated after 6 months or 2 releases (whichever is longer). And GA features can only be renamed or deprecated during major releases (e.g. between CSI v1.x to v2.x).
The text was updated successfully, but these errors were encountered: