[Feature] Managing multiple CRD versions at the same time

[Jeffwan]

Search before asking

• I had searched in the issues and found no similar feature requirement.

Description

Follow up story of #536.

We will have multiple tracking issues may update the CRDs in v0.5.0 release. It's a good time to talk about multi-version management now. I highly recommend to bump to v1beta1 CRD before we come into v1. (We expect v1beta1 would be same as v1 though)

One thing to notice is conversion does introduce webhook and it make deployment a little pretty heavy.

Use case

Use to manage multiple CRD versions and help user upgrade to new version smoothly.

Related issues

No response

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

[akanso]

do we have a compelling case for backward compatibility?

in v1beta1 are we planning to break the API, that is the CRD definition will change and the previous CRs will not parse properly?

KubeRay upcoming major version is still 0. that is, 0.5.x, it would be unusual to have the CRD version v1 when kuberay is still in "v0"

[Jeffwan]

@akanso Yes, some unhelpful fields like head.replicas should be reused. There're some fields that can be changed to use annotation instead could be removed as well.

Previous CR can still work with the webhook conversion. That's the backward compatibility the project should guarantee. Let's write more details for this one.

[kevin85421]

I will try to bump RayService from v1alpha1 to v1beta1 or v1alpha2 next week.

[kevin85421]

I will bump the CRD version to v1. In addition, after discussing with several users and experts on CRD versioning, we have decided not to go with a conversion webhook.