Easier Custom Resource client creation

[metacosm]

From @manusa in #2611:

So far we've worked on the CRD>CR consumption part. We've provided the tools to generate a CRD API client that works with any CRD API version (v1beta1 or v1). The main reason for this is that CRDs comply to a standard RESTful API with strong conventions around resource naming and location. Instead of working with CRD instances to declare this client we use a more abstract CustomResourceDefinitionContext which contains the required fields to be able to interact with via REST with Kubernetes. (So we could say that CustomResourceOperations implementation is more or less complete. ✔️

However, there's still another requirement/feature (and maybe this belongs more to the SDK) "As a Kubernetes Java developer I want to infer the Custom Resource Definitions for my Java objects automatically". ✨

Considering an abstract CusomtResourceDefinitionOperations interface (has the standard CRUD methods) which would have implementations for every API version (v1beta1 or v1), we could define a client method T crdClientFrom(Class<? extends CustomResource> customResourceClazz) (A).
The method implementation logic should run as follows:

Check latest CRD API version available in the connected cluster
Return applicable CusomtResourceDefinitionOperations interface implementation instance

Besides, another method to infer a CRD instance from a POJO would be good to have (again, this may probably fit better within the SDK project). This is trickier (probably needs a few more iterations), because there are (as of now) 2 types that represent CustomResourceDefinition. It would make sense some method such as T crdFrom(Class<? extends CustomResource> customResourceClazz) (B), depending on the APIs available on the cluster, a v1 or v1beta1 CRD instance is returned.
The implementation for this method is were we should be really creative in terms of inferring OpenAPIV3Schema from the POJO fields, annotations, JSR 303, etc.

With both A & B in place, something like this should be feasible:

kubernetesClient.crdClientFrom(MyCustomResource.class).create(CRDToolset.crdFrom(MyCustomResource.class));

or any other CRUD operation on the represented CRD k8s resource.

(IMHO)

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[alxbl]

However, there's still another requirement/feature (and maybe this belongs more to the SDK) "As a Kubernetes Java developer I want to infer the Custom Resource Definitions for my Java objects automatically". ✨

I think this is a very good use-case for people who are developing Operators in Java using javaoperator-sdk and I would like to see this supported as well.

Cheers,
Alex

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[manusa]

This should already be possible right?

[shawkins]

kubernetesClient.crdClientFrom(MyCustomResource.class)

That is now possible as client.resources(MyCustomResource.class) - it will look at the Group, Version, and Plural annotations, and if it implements Namespaced.