quarkus-operator-sdk
quarkus-operator-sdk copied to clipboard
Make it possible to generate CRDs for all detected CustomResources even when not used by a Controller
It can happen that a project might need to reference Custom Resources that are not directly under the control of the operator. While this is an atypical use case, it might be interesting to generate the associated CRDs when asked to do so.
i was trying out the joke samples - and just wanted to add that until this issue gets fixed, the only way i found to generate the CRD for jokes.samples.javaoperatorsdk.io-v1.yml was to use this directly in the pom.xml
<dependency>
<groupId>io.fabric8</groupId>
<artifactId>crd-generator-apt</artifactId>
<version>5.9.0</version>
<scope>compile</scope>
</dependency>
and then:
oc apply -f target/classes/META-INF/fabric8/jokes.samples.javaoperatorsdk.io-v1.yml
otherwise you get an api error in your JokeRequest
status:
error: true
message: |-
Error querying API: Failure executing: POST at: https://api.openshift-<your cluster domain>:6443/apis/samples.javaoperatorsdk.io/v1alpha1/namespaces/java-operator/jokes. Message: 404 page not found
hopefully that helps someone trying out the samples for the first time ! thx.
Yes indeed. This issue's existence is based on that sample's UX: you do indeed need to use the APT dependency to generate the Joke
CRD. The reason why it's not fixed: it's because I'm not sure that's a valid use case most of the time. What do people think?
I think having an api
library with only the model is useful for other projects only depending on this specific API
I think having an
api
library with only the model is useful for other projects only depending on this specific API
That's a common use case, indeed. However, this doesn't change the fact that custom resources not directly declared by your controllers won't be generated automatically by the extension. Adding the crd-generator-apt
dependency to such an api
module, would do the work but that work would end up being done again for the CRs that are directly referenced…
+1 on keeping the original apt
behaviour and generating the CRD for all the available annotated classes.
I can confirm this is a common use case, especially now that JOSDK supports dependent resources. You thus often end up with one reconciler that watches / handles multiple custom resources (a primary and one or more secondary).
I confirm the CRDs are still not generated without a reconciler. Will this be fixed soon ? Or can we have an annotation on the CRs that specifies which CRDs must be generated ?
I will revive this and see what can be done.
An initial stab at implementing this feature is provided in #399. Please give it a try and let me know if you encounter any issues.