Java Operator JUnit Extension is unusable from Quarkus

[andreaTP]

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]

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]

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]

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…