fix: able to override controller level namespace when set in annotation

[csviri]

When the namespace of a controller is set to a different value, for example:

@ControllerConfiguration(namespaces = WATCH_CURRENT_NAMESPACE, ... )

Then the quarkus.operator-sdk.namespaces configuration override is not working, thus setting the namespace in the annotation we should consider more like a default value.

[metacosm]

What use case is this suppose to fix, as this looks suspicious, the parameter that is now always false had been introduced for a reason.

[csviri]

@metacosm added description.

What use case is this suppose to fix, as this looks suspicious, the parameter that is now always false had been introduced for a reason.

The initial value is always false, but otherwise changed here:

quarkus-operator-sdk/core/runtime/src/main/java/io/quarkiverse/operatorsdk/runtime/QuarkusControllerConfiguration.java

Line 211 in 9e722e7

wereNamespacesSet = true;

For example when the controller configuraiton is set from params:

quarkus-operator-sdk/core/runtime/src/main/java/io/quarkiverse/operatorsdk/runtime/ConfigurationServiceRecorder.java

Line 48 in 9e722e7

extConfig.namespaces.map(HashSet::new).ifPresent(c::setNamespaces);

[metacosm]

Then the quarkus.operator-sdk.namespaces configuration override is not working, thus setting the namespace in the annotation we should consider more like a default value.

There is no such override: quarkus.operator-sdk.namespaces is the value that is used if no other value (at
any level) is provided, it is not supposed to override values that might have been provided. That property has the lowest precedence of all properties to set namespaces. See https://docs.quarkiverse.io/quarkus-operator-sdk/dev/index.html#quarkus-operator-sdk_quarkus.operator-sdk.namespaces. Perhaps is the documentation not clear enough?

[csviri]

Then the quarkus.operator-sdk.namespaces configuration override is not working, thus setting the namespace in the annotation we should consider more like a default value.

There is no such override: quarkus.operator-sdk.namespaces is the value that is used if no other value (at any level) is provided, it is not supposed to override values that might have been provided. That property has the lowest precedence of all properties to set namespaces. See https://docs.quarkiverse.io/quarkus-operator-sdk/dev/index.html#quarkus-operator-sdk_quarkus.operator-sdk.namespaces. Perhaps is the documentation not clear enough?

It does not make too much sense to me this way. So IMHO should be this way (precedence order):

1. controller configuration from property, thus: quarkus.operator-sdk.controllers."controllers".namespaces
2. quarkus.operator-sdk.namespaces if above not set
3. The value from annotation (if not set the default value) if above not set

Mainly it does not adds up to me, that it overrides the namespace if in the annotation the value is not set, but does not override it when it is set in the annotation. Those values should be overrideable in all cases.

[metacosm]

Then the quarkus.operator-sdk.namespaces configuration override is not working, thus setting the namespace in the annotation we should consider more like a default value.

There is no such override: quarkus.operator-sdk.namespaces is the value that is used if no other value (at any level) is provided, it is not supposed to override values that might have been provided. That property has the lowest precedence of all properties to set namespaces. See https://docs.quarkiverse.io/quarkus-operator-sdk/dev/index.html#quarkus-operator-sdk_quarkus.operator-sdk.namespaces. Perhaps is the documentation not clear enough?

It does not make too much sense to me this way. So IMHO should be this way (precedence order):

1. controller configuration from property, thus: `quarkus.operator-sdk.controllers."controllers".namespaces`

2. `quarkus.operator-sdk.namespaces` if above not set

3. The value from annotation (if not set the default value) if above not set

Mainly it does not adds up to me, that it overrides the namespace if in the annotation the value is not set, but does not override it when it is set in the annotation. Those values should be overrideable in all cases.

I don't agree and that would be a breaking change. If the user made the effort to provide a value in the annotation, then it should be taken into account, not overridden by a blanket value that applies to all controllers that are not configured. This is how this property has been designed to behave.

If this is too confusing, the appropriate solution, imo, would be to remove the quarkus.operator-sdk.namespaces property altogether (which is actually something I considered).

[csviri]

If the user made the effort to provide a value in the annotation, then it should be taken into account, not overridden by a blanket value that applies to all controllers that are not configured. This is how this property has been designed to behave.

Maybe we should think through this for v5 of JOSDK and remove this property , not sure if the value make sense in the annotation. This really depends on that how a team deploys a controller, and it is something that naturally varies on platforms.

Basically that is why I wrote: thus setting the namespace in the annotation we should consider more like a default value.

[metacosm]

If the user made the effort to provide a value in the annotation, then it should be taken into account, not overridden by a blanket value that applies to all controllers that are not configured. This is how this property has been designed to behave.

Maybe we should think through this for v5 of JOSDK and remove this property , not sure if the value make sense in the annotation. This really depends on that how a team deploys a controller, and it is something that naturally varies on platforms.

Yes, it definitely makes sense to consider cleaning things up for the next major version. I will close this PR for now, though.

[csviri]

kk, I will close the related issue