Add MCAD API groups migration plan

[astefanutti]

Closes project-codeflare/multi-cluster-app-dispatcher#352.

[z103cb]

Overall LGTM. Left some questions

[tardieu]

If we are going to force every downstream project/user to take action, it may be worth considering making other/all desirable changes to the CRD structure at the same time, so that we don't have to repeat the disruption again and again. Maybe we need first separate discussion/ADR about these changes and then decide whether to combine these efforts.

[astefanutti]

If we are going to force every downstream project/user to take action, it may be worth considering making other/all desirable changes to the CRD structure at the same time, so that we don't have to repeat the disruption again and again. Maybe we need first separate discussion/ADR about these changes and then decide whether to combine these efforts.

@tardieu that's a good point. It's worth noting that those "structural" changes, within the CRDs, could be handled with the usual CRD versioning mechanism, possibly using conversion webhooks (or CEL based conversion in the future) to automate it, as opposed to changes to identifying fields, like the API group.

That being said, I agree it'd be worth assessing if any major breaking changes could be piggy-backed with that effort.

@asm582 @z103cb could you please provide your input here?

[asm582]

If we are going to force every downstream project/user to take action, it may be worth considering making other/all desirable changes to the CRD structure at the same time, so that we don't have to repeat the disruption again and again. Maybe we need first separate discussion/ADR about these changes and then decide whether to combine these efforts.

@tardieu that's a good point. It's worth noting that those "structural" changes, within the CRDs, could be handled with the usual CRD versioning mechanism, possibly using conversion webhooks (or CEL based conversion in the future) to automate it, as opposed to changes to identifying fields, like the API group.

That being said, I agree it'd be worth assessing if any major breaking changes could be piggy-backed with that effort.

@asm582 @z103cb could you please provide your input here?

Thanks, @astefanutti and @tardieu - "structural changes" as mentioned are bound to happen in the future. For the features that are required for the immediate release, I don't think there is anything major that needs to be added to the effort.

[z103cb]

If we are going to force every downstream project/user to take action, it may be worth considering making other/all desirable changes to the CRD structure at the same time, so that we don't have to repeat the disruption again and again. Maybe we need first separate discussion/ADR about these changes and then decide whether to combine these efforts.

@tardieu that's a good point. It's worth noting that those "structural" changes, within the CRDs, could be handled with the usual CRD versioning mechanism, possibly using conversion webhooks (or CEL based conversion in the future) to automate it, as opposed to changes to identifying fields, like the API group.

That being said, I agree it'd be worth assessing if any major breaking changes could be piggy-backed with that effort.

@asm582 @z103cb could you please provide your input here?

I think is OK to try to piggy back everything if all the items are known at this point in time. From my perspective (KubeRay API server integration) the sooner the final API is available the better.

The only items that I can think that would fall into structural category are:

• Is enabling status sub resource for the Quota Management CRD(s) (even if is just empty and not populated in the first couple of releases).
• Move AppWrapper quota request from label to element of AppWrapper object

[Sara-KS]

For the TorchX+MCAD piece, I plan to try to support both the old version and the new version to help with the transition for users on different systems. Is there a clear way to tell which CRDs are in use that does not require administrative type permissions?

[astefanutti]

For the TorchX+MCAD piece, I plan to try to support both the old version and the new version to help with the transition for users on different systems. Is there a clear way to tell which CRDs are in use that does not require administrative type permissions?

One possible solution would be to query the discovery API, and check if the new API group is present. Generally most users are granted permission to query the discovery API, which is what's used when running the kubectl api-resources command.

[z103cb]

LGTM, but I would wait for the others to chime in before considering the ADR approved. @tardieu needs to sign off on this ADR.

[tardieu]

+1 for one-shot.

[anishasthana]

Approved from my perspective.

[z103cb]

Approved.

[dimakis]

LGTM, makes logical sense.

[anishasthana]

I think we have quorum for the approvals. The work has already somewhat begun -- I'm going to go ahead and merge this. If in future we require additional revisions, we can always propose a new ADR / add an addendum to this one.