Change one of the samples to Contract first (CRD->Java) source generation

[csviri]

Fabric8 now supports contract first approach, thus generating Java class representation from CRD; not other way around, as we have it in our samples.

There are different opinions which approach should be used, let's delegate this decision to the users; however it would be beneficial to migrate one of our samples to contract first approach to showcase that.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[derlin]

Interested in this one :)

I am however hesitating on which sample to use. On the one hand, using mysql-schema would be more interesting, as there are many properties in spec/status, some of which may benefit from CRD validation rules (https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules). On the other hand, using contract-first makes the samples less transparent / less easy to read. In this regard, transforming leader-election (which is very basic) to contract first would be better.

What do you think ?

[csviri]

I'm fine with the leader election too, just add pls a readme there to explain that. Thx!

[derlin]

Another question: when we have a CRD (under resource) and generate the Java code, by default fabric8 will generate a CRD back from Java. So the question is: is this back-and-forth okay, or should we instead turn of crd generation and copy the CRD from resources to target during mvn package ?

To me both have pros and cons:

if we regenerate the CRD, we can thus generate e.g. v1 and v1beta1 from a single v1 CRD, but we lose any custom addition to the CRD (e.g. custom singular and plural names, custom validation rules, etc.). Keeping the original CRD has exactly the opposite advantages.

I would personally go with 2 - keep the original, as if we go contract-first I guess this is because we want to use specific, unsupported features. What do you think ?

[csviri]

Hi @derlin I think the back and fort does not make much sense to me. I think we should just simply generate the Java code. Could you maybe create a draft PR to better see where is the problem? thx

[derlin]

@csviri I couldn't agree more. I am used to using JOSDK through quarkus-operator-sdk, which applies CRDs automatically and thus would expect them to be in a specific place (and not sure most features would work without the regeneration), but in this case the back-and-forth makes no sense.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[derlin]

Shouldn't this issue be closed?

[csviri]

yes, will :)