Cover scenario when installing the operator and using it in different namespaces

[Sgitario]

At the moment, the instructions and the CI pipeline cover the following scenario:

Given an operator 
When we install it in one Kubernetes namespace
And we install a custom resource for this operator in the same namespace
Then the operator reacts as expected

However, it's a good practice that the operator is installed in a different namespace and watches the custom resources from another namespace. So, this new scenario should be also covered:

Given an operator 
When we install it in one Kubernetes namespace
And we install a custom resource for this operator in another namespace
Then the operator reacts as expected

[metacosm]

This should already be covered: you can configure which namespace(s) the operator needs to watch so it should already be able to monitor custom resources in namespace(s) other than the one it's being installed in. This is done by either using the @ControllerConfiguration(namespaces = "foo, bar") annotation on your Reconciler or by using the quarkus.operator-sdk.controllers.<controller name>.namespaces=foo,bar property. See https://github.com/quarkiverse/quarkus-operator-sdk/blob/main/integration-tests/src/main/resources/application.properties#L5 for example.
Or am I misunderstanding something?

[Sgitario]

This should already be covered: you can configure which namespace(s) the operator needs to watch so it should already be able to monitor custom resources in namespace(s) other than the one it's being installed in. This is done by either using the @ControllerConfiguration(namespaces = "foo, bar") annotation on your Reconciler or by using the quarkus.operator-sdk.controllers.<controller name>.namespaces=foo,bar property. See https://github.com/quarkiverse/quarkus-operator-sdk/blob/main/integration-tests/src/main/resources/application.properties#L5 for example. Or am I misunderstanding something?

Yes, I see this is already supported, though what I suggest is to cover this use case as part of the instructions and the CI pipeline, first to let users that this is the recommended configuration, and second to ensure it's working as expected.

[metacosm]

OK, makes sense.

[scrocquesel]

This is usually configured by env var but in some old versions setting a env var named quarkus.operator-sdk.controllers.<controller name>.namespaces didn't work. What we did was to add in application.properties a mapping like
quarkus.operator-sdk.controllers.<controller name>.namespaces=$(QUARKUS_OPERATOR_SDK_CONTROLLERS_CONTROLLER_NAME_NAMESPACES).
TBH, I don't know if this was fixed but covering the use case in the CI pipeline could reveal this bug if it still exists.