Support Conversion Hook Configuration in CRD Generation

[csviri]

Is your enhancement related to a problem? Please describe

Conversion hooks are defines in CRD, might be nice to support this.

https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#configure-customresourcedefinition-to-use-conversion-webhooks

Describe the solution you'd like

Probably with an annotation, sample:

@Group("sample.javaoperatorsdk")
@Version(value = "v1", storage = false)
@Kind("MultiVersionCustomResource")
@ShortNames("tcr")
@ConversionHook(name="my-conversion-service",namespace="default",path="/convert"", port=443, ... )
public class MultiVersionCustomResource
    extends CustomResource<MultiVersionCustomResourceSpec, Void> {

}

Describe alternatives you've considered

No response

Additional context

No response

[andreaTP]

If I read it correctly, the conversions field is part of the Spec and it's not a top-level concept:
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#customresourcedefinitionspec-v1-apiextensions-k8s-io

I will be unsure how to implement this support given that we don't have explicit management of "versions" too.

i.e. given multiple versions of the same CRD, where the conversions should be declared?

Looking for alternatives, cc. @metacosm @shawkins

[csviri]

Yes, absolutely, it is not nice this way. Just was not able to think any better alternative.

[manusa]

As agreed during the internal meeting, we'll investigate the improvement of our model to have a top-level CustomResourceDefinition entity/annotation/...

Currently, the CRD generation uses a convention approach where users are able to annotate custom resource POJOs that will later be consolidated into a custom resource definition by the APT. The convention matches the POJO name for each version and then consolidates everything into a single CRD.

The improvement should keep compatibility with the current convention approach. However, we could introduce this top-level CRD entity where we could explicitly define the versions, validation hooks, and of course the requested conversion hooks.

[metacosm]

I think a similar approach had indeed been discussed a while ago.

[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!

[csviri]

I still plan to work on this. This comment is mainly for @Stale :)

[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!