kuberay
kuberay copied to clipboard
ray-project
[Feature] Support CRD versioning
Search before asking
- [X] I had searched in the issues and found no similar feature requirement.
Description
The current kuberay CRD has changed a few times in the past year. Some of these changes have invalidated existing RayCluster configs, resulting in added migration complexity. In particular, if you have existing RayClusters that were created with the old CRD, it's not clear how to correctly migrate them to the new CRD without affecting users.
Kubernetes recommends two different approaches to CRD versioning:
- Multiple versions at once
- Webhook conversion
It would be great to understand which approach makes the most sense of kuberay and add versioning to the CRD going forward.
Use case
Supporting upgrades to new Ray Operator and CRD versions without breaking existing RayCluster configs.
Related issues
No response
Are you willing to submit a PR?
- [X] Yes I am willing to submit a PR!
I agree with that changes result in added migration complexity.
At the beginning, there are three CRDs in this repo. We have discussed in the last year and merge them into one CRD. I think we will work on this CRD , and the ray-operator controller will be compatible with all versions of the CRD. So Multiple versions at once looks good to me.
em. as @chenk008 said, there're historical reasons for the breaking changes. Current APIs is a result of redesign which does introduce the breaking changes.. version management will be improved after the unification.
Based on previous experience, we try not to introduce webhook for the conversion. Explicitly specifying the version sound better to me and we do have good practice in other projects.
- Any API changes should bump crd version. v1alpha1 -> v1alpha2 -> v1beta1 -> v1 -> v2alpha2 etc
- Suggest user to use pinned version. kuberay v0.2.0 etc.
- Release testing will cover upgrade tests and migration guidance should be provided
