Confusing hard-coded v1 expectation for CRD Yamls

[tombentley]

Bug Report

What did you do?

I wrote a reconciler test along the lines of the one generated by the quickstart. The one difference between the quickstart and what I'm trying to do is I want to use a CRD-first approach (rather than Java-first approach) for my operator. So I'm generating by CRD classes using the Fabric8 plugin. This seems to be working fine.

What did you expect to see?

I expected to be able to use the LocallyRunOperatorExtension, maybe needing to tell it where my CRD YAML lives.

What did you see instead? Under which circumstances?

The test dies with this stacktrace:

java.lang.IllegalStateException: Cannot apply CRD yaml: /META-INF/fabric8/kafka-proxies.kroxylicious.io-v1.yml

	at io.javaoperatorsdk.operator.junit.LocallyRunOperatorExtension.applyCrd(LocallyRunOperatorExtension.java:192)
	at io.javaoperatorsdk.operator.junit.LocallyRunOperatorExtension.applyCrd(LocallyRunOperatorExtension.java:169)
	at io.javaoperatorsdk.operator.junit.LocallyRunOperatorExtension.before(LocallyRunOperatorExtension.java:157)
	at io.javaoperatorsdk.operator.junit.AbstractOperatorExtension.beforeEachImpl(AbstractOperatorExtension.java:148)
	at io.javaoperatorsdk.operator.junit.AbstractOperatorExtension.beforeEach(AbstractOperatorExtension.java:79)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
Caused by: java.lang.IllegalStateException: Cannot find CRD at /META-INF/fabric8/kafka-proxies.kroxylicious.io-v1.yml
	at io.javaoperatorsdk.operator.junit.LocallyRunOperatorExtension.applyCrd(LocallyRunOperatorExtension.java:180)
	... 6 more

The expectation that my CRD lives in /META-INF/fabric8/ is a bit annoying, but bearable.
A bigger problem is this seems to assume that my CRD is supporting a v1, which is not the case (I'm starting with a v1alpha1).
There doesn't seem to be any way to override this behaviour. So it looks like I'm forced to declare my CRD in a file with a really confusing name.

Environment

N/A

Possible Solution

Allow passing the CRD resource name in the call to LocallyRunOperatorExtension.withReconciler() would appear to be a reasonable API for allowing people to use the extension without hardcoding naming assumptions about CRD resources.

Additional context

[csviri]

Thx! we will take a look, pls let is know if you plan to create a PR for this on your own :)

[tombentley]

Sorry, but I don't have time right now to provide a PR for this myself.

I guess another possible explanation for the v1 is it's referring to the version of CustomResourceDefinition. But if so then such a naming scheme is still pretty weird because it includes the group name of one API but the version of another.

[csviri]

I think we just simply don't have this properly covered for tests, since mostly users use the CRD generator from java classes, will add support for this soon.

[metacosm]

Yes, the v1 refers to the CRD spec version, not your Custom Resource version. The other possible value is v1beta1. I agree that this is confusing and should probably include the CR version as well.

[metacosm]

@tombentley Could you try the #2569 PR and let us know if this addresses your issue?

[tombentley]

@metacosm #2569 works for me. Thanks!

[csviri]

Hi added an additional PR to simplify the API, hope it helps.