Description

Right now, if conversion strategy is left as None nothing really happens other than the apiVersion field gets updated. HOWEVER! There is a caveat.

https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/

What happens to the object that is being returned while serving the read request depends on what is specified >in the CRD's spec.conversion:
if the default strategy value None is specified, the only modifications to the object are changing the apiVersion >string and perhaps pruning unknown fields (depending on the configuration). Note that this is unlikely to lead to good results if the schemas differ between the storage and requested version. In particular, you should not use this strategy if the same data is represented in different fields between versions.

We've seen this happen when we applied a "breaking change" for the Resource type object to an existing cluster. The breaking change was that we removed the interval field. The object was updated and the interval field was removed because it's an unknown field. So it was pruned.

This turned out to be an okay change, but this can get a lot scarrier. So we either should disable conversion or implement a conversion webhook. Both options are valid approaches.

Kubebuilder book example https://book.kubebuilder.io/multiversion-tutorial/conversion.html?highlight=conversion#implementing-conversion.

Done Criteria

• Conversion strategy is no longer None
  - [ ] Conformance scenario is still working
• Add e2e test cases to showcase the conversion working as expected ( most likely requires some kind of new version to exist though ) ( might be able to mock something )
• Successful demonstration in Review