Manage versioning of the CheCluster CRD

[davidfestal]

Is your enhancement related to a problem? Please describe.

Now that we provide an OpenAPI schema for the CheCluster Custom Resource, we would need to upgrade the version of the CRD when introducing new fields. It seems this is necessary to ensure backward-compatibilty with already-existing CRDs in a cluster, and proper updates of CSVs in OperatorHub.

If we release release new Operator versions in OperatorHub without correctly managing the CRD versionning, users will face the following problems:

• Automatic update through OperatorHub will not update the CRD (since it already exists in the cluster and it is a cluster-wide resource). So users won't be able to use the new properties.
• If ever the CRD would be updated manually, then the new fields would be available in Openshift 4 console doc and yaml completion, even for previous versions of installed Che that would not have been automatically upgraded (this second case is not critical since this PR only adds new fields).

Describe the solution you'd like

The established way to do this is described here: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/#specify-multiple-versions.

This issue is about setting this up and testing updates with a new version of CRD to ensure everything works as expected according to the Kubernetes docs.

We should also update OLM-related scripts in order to update the CRD version consistently, or at least check that the generated CRD yaml is not modified without having a new API version created.

[tolusha]

@davidfestal
I am wondering how I can test updates of the operator with a new version of CRD?

[tolusha]

Useful links
https://github.com/operator-framework/operator-sdk/blob/master/doc/user-guide.md
https://github.com/operator-framework/operator-sdk/blob/master/doc/user/migrating-existing-apis.md
https://docs.openshift.com/container-platform/4.2/operators/understanding-olm/olm-understanding-dependency-resolution.html

[tolusha]

I've pushed into a branch my efforts to automate crd versioning
[1] https://github.com/eclipse/che-operator/tree/ab/versions

[tolusha]

The issue is postponed

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[tolusha]

Eclipse Che operator already manages several versions of eclipse-che CRD