Overriding the resource API version in client.resources(...)

[scholzj]

In the past versions of Fabric8 Kubernetes Client, I was able to create the MixedOperation instance for managing my custom resources using the customResources(...) method. It allowed me to specify my CRD class, the List class as well as the custom CustomResourceDefinitionContext instance where I was able to configure the APi version of the resource I want to use. This was super useful when working with multiple different versions of my custom resource, such as v1beta1 and v1.

However, in the recent versions of Fabric8, it seems this option is gone. I can either us the resources(...) method. But that always takes the APi version from the @Version annotation on the CRD class. Or I can use the genericKubernetesResources() method, which allows me to specify any API version. But it does not let me use my own CRD classes. It always uses the GenericKubernetesResource type :-(.

Is there some way how to use my own CRD types while also specifying the API version manually and not through their @Version annotation?

Just to give some background ... Strimzi uses the same CRD class as multiple resource versions. So, for example, the Kafka class is used for both v1beta2 as well as v1. But it can have only one @Version annotation. So in order to be able to easily transition between the versions without changing the annotation, we would need to configure the API version differently.

[manusa]

AFAIR the practice of reusing the same class to represent multiple CRD versions is something that was to be discouraged.
The idea was to encourage the usage of different CRD classes for each apiGroup-version combination.
I remember discussing this internally with @metacosm and maybe @shawkins. Maybe they can provide more details.

[scholzj]

Ok, fair enough. I guess I will need to deal with the GenericKubernetesResource.

In Strimzi, we have the same class for multiple API versions, and I think that - apart from this aspect - it works pretty fine. The main advantage is that we need minimal code changes to move from one API version to another, as it is always the same class. But I guess we might also be one of the very few Fabric8 users who have their own CRD generator etc. So it might not be useful to most other Fabric8 users.

[manusa]

AFAIR, the proposed pattern to reuse functionality was to implement logic in parent classes and then expose versioned child classes with the appropriate annotations. I think there was even an example somewhere, but I can't find it now.