Chris Laprun

Then if it's for testing, people will know when deploying the namespace they want to watch and can therefore pass it via the `quarkus.kubernetes.namespace` property or am I missing something?

Wondering if something like https://quarkus.io/guides/deploying-to-kubernetes#environment-variables-from-fields could be used for this… 🤔

This will be addressed with the update to JOSDK 3.0.0 where the default value for namespaces (i.e. watching all namespaces) will be made explicit. See https://github.com/java-operator-sdk/java-operator-sdk/pull/1177 for more details.

Hi @tonswieb, you should be able to try use a SNAPSHOT version until we release a newer version. I just merged some recent changes and the snapshot should be propagated...

> @metacosm is there a way to force all namespaces using the environment variable: QUARKUS_OPERATOR_SDK_NAMESPACES > I was going to tell you that you need to use `QUARKUS_OPERATOR_SDK_CONTROLLERS__NAMESPACES` instead but...

> 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...

We will have better support for RBACs with dependent resources since we will know exactly which dependent resources your operator will need and with the trait behavior (see https://github.com/java-operator-sdk/java-operator-sdk/pull/963) we...

For the time being, though, you can add a valid yaml fragment in `src/main/kubernetes` that contains the stanza that needs to be added to your RBAC and it will be...

It's empty during tests at the very least, if you don't explicitly set it, which is only possible, as far as I'm aware, if you're using `QuarkusProdModeTest`.

Yes but that means that, when not using `QuarkusProdModeTest`, the tests will generate invalid manifests.