Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java Operator JUnit Extension is unusable from Quarkus #328

Open
andreaTP opened this issue Apr 26, 2022 · 3 comments
Open

Java Operator JUnit Extension is unusable from Quarkus #328

andreaTP opened this issue Apr 26, 2022 · 3 comments

Comments

@andreaTP
Copy link
Contributor

Trying to use the Java Operator JUnit Extension from a project using the Quarkus Operator SDK results in multiple errors and, currently, is impossible to run the tests.

Here you can find a minimal reproducer:
https://github.com/andreaTP/operator-junit-repro

Additional considerations:

  • despite having set quarkus.operator-sdk.start-operator=false seems that there are 2 operators started:
2022-04-26 17:42:17,222 INFO  [io.jav.ope.Operator] (main) Operator SDK unknown is shutting down...
...
2022-04-26 17:42:17,271 INFO  [io.jav.ope.Operator] (main) Operator SDK 2.1.4 is shutting down...

and there are consistently duplicated logs.

  • the JUnit extension relies on the fact that CRDs are generated in a specific location maybe we should consider adding the crd-generator-apt as a transitive dependencies (or make the location more easily configurable)

  • the current blocking issue seems to be the fact the framework is unable to load the configuration for the reconciler:

2022-04-26 17:59:29,711 WARN  [Default ConfigurationService implementation] (main) Configuration for reconciler 'examplereconciler' was not found. Known reconcilers: None.

cc. @DGuhr @metacosm @csviri

@scrocquesel
Copy link
Member

Do you need both Local and Remote support ? Remote would require the image to be built but I'm not sure quarkus do it before running the tests. Like the OLM testing, it could not be a mvn one liner as with josdk.

For local, I think that what you are asking can interest Quarkus k8s development more broadly as part of Dev Service experience. Maybe with quarkus-kind or quarkus-minikube extension, a cluster can be created if not detected during dev and tests.

Nonetheless, what about a custom QuarkusTestResourceLifecycleManager that can wrap an AbstractOperatorExtension to just prepare the cluster and let quarkus run the app normally. Meaning, the JOSDK JUnit extension is not responsible of creating and running the operator instance because it should not in the first place.

@andreaTP
Copy link
Contributor Author

I forgot to give more context to this issue.
We do have a working setup for local/remote testing in the Keycloak operator:
https://github.com/keycloak/keycloak/blob/9541852a9bf7d36647d4723d3420556f4b75ac92/operator/src/test/java/org/keycloak/operator/ClusterOperatorTest.java#L39

And that's the reason why I contributed this functionality to the JOSDK.
To pay tech debt, we have attempted to use the JUnit extension and failed.
But it's definitely possible to do it!

@metacosm
Copy link
Member

Nonetheless, what about a custom QuarkusTestResourceLifecycleManager that can wrap an AbstractOperatorExtension to just prepare the cluster and let quarkus run the app normally. Meaning, the JOSDK JUnit extension is not responsible of creating and running the operator instance because it should not in the first place.

That's the approach we decided to take: we will write a Quarkus test resource that deals with setting up the cluster, though I'm not sure how much code we'll be able to reuse from the JOSDK JUnit extension…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants