Closed Obirah closed 1 year ago
This makes sense. How would you want to configure this, though?
I would love to see a mechanism, where I can configure the following two things:
Either opt-in to CRD generation for specific groups:
quarkus.operator-sdk.crd.generator.include-groups=com.mygroup.myoperator
Or opt-out from CRD generation for specific groups:
quarkus.operator-sdk.crd.generator.exclude-groups=com.mygroup.otheroperator
Alternatively, I could also imagine the same mechanism with CustomResource
class names:
Include:
quarkus.operator-sdk.crd.generator.include-resources=MyOperatorResource
Exclude:
quarkus.operator-sdk.crd.generator.exclude-resources=OtherOperatorResource
Of course, the best way would be to have all of those options as I can imagine all of them might be useful in certain operator use-cases.
Wonder if it makes sense to filter also on Kind
.
Wonder if it makes sense to filter also on
Kind
.
Basically, the second part of the suggestion in my previous comment is a filtering on Kind
as the Name of the CustomResource
class translates to Kind
when the CRD is generated.
Ahh, yes sorry :) That makes sense imo. Since we are generating from classes.
On the other hand it can be a little fuzzy, if on class not on kind, since a kind can have multiple classes. If there are multiple versions for a CR. But this is not that big issue.
I settled for quarkus.operator-sdk.crd.exclude-resources
passing the resources' FQNs for now. I believe this should cover most of the cases, especially considering that using quarkus.operator-sdk.crd.generate-all
, you can already include non-reconciler associated resources for CRD generation, the ones associated with reconcilers being already automatically generated on demand (unless quarkus.operator-sdk.crd.generate
is set to false, in which case CRD generation is completely disabled).
Thank you for implementing this feature, @metacosm. :) I have a follow-up question: I tried to use quarkus.operator-sdk.crd.exclude-resources
but my external CRD is tied to a reconciler and it seems like because of that the yaml file is generated anyway. I don't want to set quarkus.operator-sdk.crd.generate
to false because I have three other CRDs that are supposed to be generated, but I don't want to have the external one generated even though it is tied to a reconciler. Is it currently possible to achieve this with a combination of config options?
Thank you for implementing this feature, @metacosm. :) I have a follow-up question: I tried to use
quarkus.operator-sdk.crd.exclude-resources
but my external CRD is tied to a reconciler and it seems like because of that the yaml file is generated anyway. I don't want to setquarkus.operator-sdk.crd.generate
to false because I have three other CRDs that are supposed to be generated, but I don't want to have the external one generated even though it is tied to a reconciler. Is it currently possible to achieve this with a combination of config options?
So, if I understand correctly, you'd like to exclude a reconciler's primary resource from triggering the generation of the associated CRD, right? If that's indeed the case, it might not indeed not be possible at this point. Let me look into it.
Thank you for implementing this feature, @metacosm. :) I have a follow-up question: I tried to use
quarkus.operator-sdk.crd.exclude-resources
but my external CRD is tied to a reconciler and it seems like because of that the yaml file is generated anyway. I don't want to setquarkus.operator-sdk.crd.generate
to false because I have three other CRDs that are supposed to be generated, but I don't want to have the external one generated even though it is tied to a reconciler. Is it currently possible to achieve this with a combination of config options?So, if I understand correctly, you'd like to exclude a reconciler's primary resource from triggering the generation of the associated CRD, right? If that's indeed the case, it might not indeed not be possible at this point. Let me look into it.
Yes, exactly. My operator provisions a resource that is handled by another operator and has a reconciler that is analyzing the status the other operator writes into that dependent resource and will perform further tasks based on that.
Actually, did you try excluding your CR in your operator's application.properties file using quarkus.operator-sdk.crd.exclude-resources=<fully qualified class name of your primary resource>
? This seems to prevent the CRD from being generated in my case (though this might have consequences on other downstream processes such as automatically applying the CRD to the cluster or OLM bundle generation).
Oh yes, I'm sorry I didn't describe the problem correctly, you are right. It is possible to exclude the CR, the yaml file is not generated but then a downstream error occurs (quarkusDev
task with generate=true and apply=false):
java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
[error]: Build step io.quarkiverse.operatorsdk.bundle.deployment.BundleProcessor#generateBundle threw an exception: java.lang.IllegalStateException: Missing owned CRD data for resources: [my.crd.package] for bundle: my-operator
Yes, that's expected: the OLM generator needs the CRD to work properly. So either you disable bundle generation or you need to provide the CRD to the generator. Then again from what you describe, it looks like for your reconciler the CRD is more like a required one than an owned one and this particular case is not currently supported…
Currently (as far as I'm aware of), the quarkus-operator-sdk only allows users to either enable or disable CRD generation. In my opinion, it should be possible to filter which
CustomResource
implementations are used to generate CRDs (e.g. only generate CRDs for certain groups).My use-case is the following: I want to implement a reconciler for a CustomResource that belongs to another operator. The reconciler's only job is to watch the status of the CustomResource and modify the CustomResources that belong to my operator depending on the watched status. As the CRD already exists on the cluster and belongs to another operator, I don't need that CRD to be generated even though I'm implementing
CustomResource
and using it in an reconciler.