Support multiple versions of a CRD

[csviri]

Within one CRD there could be multiple versions defined, we need to explicitly support this.

[stoetti]

@csviri Is this on the roadmap in the near future?

[csviri]

@stoetti yes, this should be actually one of the priorities in the close future.

pinging also @metacosm

[metacosm]

This should actually work already, no? If not, could you explicit a scenario that doesn't work?

[csviri]

@metacosm good question, went though again on the docs:
https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning

1. If we see this in a way that we are the client only of the API, and the conversion hooks are properly configured for a custom resource, the migration can be seamlessly done by upgrading the operator to support JUST the most recent version of a CR.
   While Kubernetes API should support multiple versions at the same time, the intention is that the clients (in this case the operator) is migrated eventually to the new version. So it's not the case that we have to support 2 versions of the same CR at the same time.
   To be honest I don't fully understand what happens if the conversion strategy is None (maybe worth to try it out).

2. In addition to that, supporting conversion webhooks is out of the scope of the framework IMHO, or could be part of an isolated subproject of the SDK (not the framework), but that is a longer discussion and/or an other issue.

So IMHO, if nobody else sees it otherwise (@metacosm @stoetti @adam-sandor ? ) we are actually good on this. There is nothing to be done. I would even close the issue.

[stoetti]

I gave it a try without using the conversionStrategy 'None'. In that case k8s just changes the apiVersion to the version thats marked with stored=true. This obviously leads to a deserialization-error if there is an incompatible change in the CRD.

I will work on a sample with a conversion webhook and see if there are any aspects that are worth building into a subproject. From the documentation the conversion-webhook is just a simple REST endpoint serving a specific interface.

[csviri]

I gave it a try without using the conversionStrategy 'None'. In that case k8s just changes the apiVersion to the version thats marked with stored=true. This obviously leads to a deserialization-error if there is an incompatible change in the CRD.

yes, just don't know how we would support that, probably does not make sense at all to do. Not sure how this is meant to be used, probably would be worth asking on kuberentes forums.

I will work on a sample with a conversion webhook and see if there are any aspects that are worth building into a subproject. From the documentation the conversion-webhook is just a simple REST endpoint serving a specific interface.

Sure, pls do, what I mean is since this is a mapping basically between json structures there is not much that can be done on a framework level to support this. Setting up such a service is already quite simple using just an application framework (spring, quarkus).

[metacosm]

From my perspective, different versions should be backed by different POJOs (though I understand there might be cases where that's not practical), each "registered" using a different version annotation so there shouldn't be a deserialization issue. Of course, if there is no backing object, there really is nothing the SDK can do… :)

[csviri]

(Sorry this was an accident closing it)

Maybe I don't understand this correctly, but the point of these conversion webhooks is to avoid to thinkin about multiple versions at the same time on client side. So having a conversion hook, basically makes it transparent for the client what version is actually used.
Thus, if somebody has an operator, and there is a new version of CRD (with a conversion servcie / webhook handler) in place, the operator can seamlessly migrate, just supporting one version in a time.
But will have to try it out.

[metacosm]

Well, this would only work if your client can handle whatever the server returns, right? So even if you only want to keep one version to deal with on the client, there still needs to be a POJO on the client that's able to handle the converted version.
That said, I'm not super familiar with conversion webhooks so maybe I'm missing something.