Add a conversion hook to ensure CRD apis can be converted from v1alphav1 to v1

[phantomjinx]

Since one version of a CRD api can be stored in the etcd, other versions are converted into this version. Without a conversion hook, the only migration that takes place is the api version number. In order to facilitate the conversion of properties then a conversion hook should be added and broadcast to the cluster.

Reference: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#before-you-begin

[phantomjinx]

Looking into this, the evidence indicates that a conversion webhook is unnecessary for the dropping of the version property.
Experiment:

1. Deploy the v1 CRD:

cd deploy
kustomize --load-restrictor LoadRestrictionsNone build setup | kubectl apply -f -

2. Create a v1alpha1 version file of the CR as hawtio_v1alpha1_hawtio_cr.yaml, eg.

apiVersion: hawt.io/v1alpha1
kind: Hawtio
metadata:
  name: hawtio-online-v1alpha1
spec:
  type: Namespace
  replicas: 1
  version: 1.0.0
  auth:
    clientCertCheckSchedule: "* */12 * * *"
    clientCertExpirationPeriod: 24

  resources:
    limits:
      cpu: "1"
      memory: 200Mi
    requests:
      cpu: 200m
      memory: 32Mi

3. Deploy the v1alpha1 CR

oc apply -f hawtio_v1alpha1_hawtio_cr.yaml

4. Get the contents of the CR from the cluster

oc get Hawtio -o yaml

The resulting data will indicate show:
a. the hawtio api version has been converted to v1
b. the version property has been dropped from the spec

Therefore, this indicates that a new v1alpha1 CR will be automatically converted upon application to the cluster.

The remaining question is whether an existing Hawtio CR that is already installed on a cluster under the v1alpha1 CRD, upgraded in the same manner when the new v1 CRD is installed. At this point, looking at the history of other projects, the initial answer to this question is that this is the case.

[tadayosi]

@phantomjinx So do you say that all these happen because we still keep apis/hawtio/v1alpha1? Or do these happen without it? If we don't need it, I still think we can delete it as well.

[phantomjinx]

@tadayosi
Best practice suggests that we should deprecate then remove later. If we delete then the CRD will overwrite any installed and any Hawtio CRs already on a cluster will no longer be valid due to lacking the api/hawtio/v1alpha1.
Am not against deleting it entirely but aware we have to consider an environment where we might need to co-exist with fuse-console / hawtio-1.0.

[tadayosi]

@phantomjinx So, if the user deploys an old CR with hawt.io/v1alpha1 the new operator still operates on the CR and creates a new hawtio-online instance? If so we'd need to find a way to show some warning to migrate to v1 to users.

[phantomjinx]

Thinking about this some more ...

There would be 2 issues with this use-case:

1. The v1alpha1 CR would contain a version which would be lost given the storage of the CRD would be set to v1 and preserveUnknownField is set to false by default. That would mean that the fuse-console operator would no longer know which version of fuse-console to install. So maybe we need to set preserveUnknownField to true in order to retain the version as a backward compatible feature;
2. Perhaps if a fuse-console labelled hawtio-online is already installed in the namespace of the v1alpha1 CR (identity by label or existence of version property??), we make a point of not installing a new hawtio-online?? (not sure this would work)

[tadayosi]

@phantomjinx

1. The v1alpha1 CR would contain a version which would be lost given the storage of the CRD would be set to v1 and preserveUnknownField is set to false by default. That would mean that the fuse-console operator would no longer know which version of fuse-console to install. So maybe we need to set preserveUnknownField to true in order to retain the version as a backward compatible feature;

I still don't see why we need preserveUnknownField. The Hawtio CRD has both v1 and v1alpha1 definitions. That would mean the version won't be lost unless the user rewrites the CR version to v1, will it?

2. Perhaps if a fuse-console labelled hawtio-online is already installed in the namespace of the v1alpha1 CR (identity by label or existence of version property??), we make a point of not installing a new hawtio-online?? (not sure this would work)

Isn't it just a matter of writing some migration guide from Fuse Console to Hawtio Online v2? Probably 100% automated migration experience wouldn't be expected.

[phantomjinx]

@phantomjinx

I still don't see why we need preserveUnknownField. The Hawtio CRD has both v1 and v1alpha1 definitions. That would mean the version won't be lost unless the user rewrites the CR version to v1, will it?

Once the CRD is installed, the storage version becomes v1. Therefore, existing v1alpha1 CRs will be 'upgraded'. My contention is that with 'preserveUnknownField' defaulting to false then any field not in the schema is removed, hence the version will then be lost. I'll try doing a test to confirm this is a thing.

Isn't it just a matter of writing some migration guide from Fuse Console to Hawtio Online v2? Probably 100% automated migration experience wouldn't be expected.

Sure. No problem with doing that.

[phantomjinx]

Use case 1

Install Hawtio then after fully installed, install fuse-console.

Result

Failed installation due to pending operator and error indicating that the conflict between the 2 CRDs cannot be reconciled.

[phantomjinx]

Use case 2

Install fuse-console via catalog / operator then upgrade the CRD to v1.

Result

If fuse-console is already installed by the operator then no errors occur either in the operator or application. However, points to note:

• executing oc get hawtio displays a CR that no longer contains the version property
• making any change to the CR results in a re-deploy of the app. However, now the operator has changed the deploy resource image property to

        image: registry.redhat.io/fuse7/fuse-console-rhel8:latest
                                                            ^^^^^

• Removing the CR, uninstalls fuse-console. Creating a different CR no longer stores the version property (despite the OS console UI still displaying it). Consequently, the image installed is again marked with the latest tag.

While the latest tag happens to associate with the default version property value that is no longer present, this may be a problem if an older fuse-console version was installed or that a specific version was required.