feat: allow reconcilers to override their own configuration

[metacosm]

Signed-off-by: Chris Laprun claprun@redhat.com

[csviri]

What is the use case for this change?

Would be good to document it at least as Javadoc on the interface

[metacosm]

What is the use case for this change?

This allows for Reconciler implementations to customize their configuration based on runtime information before being registered in situations where programmatic configuration via manually created ControllerConfigurationOverrider might not be easy or straightforward, like the Quarkus extension (and could potentially simplify the Spring Boot starter as well).

[goldmann]

I like this approach. It will definitely make my life easier where I have many label selectors that I'm adjusting based on two sources: a Map in the code and env variables set at deployment time. And this multiplied by a number of controllers.

[xstefank]

The only thing I don't understand is why it's not applied the first time getConfigurationFor is called.

[csviri]

What is the use case for this change?

This allows for Reconciler implementations to customize their configuration based on runtime information before being registered in situations where programmatic configuration via manually created ControllerConfigurationOverrider might not be easy or straightforward, like the Quarkus extension (and could potentially simplify the Spring Boot starter as well).

I see thank you, makes sense, just some remarks:

Just for the record: In general in v5 we aimed to remove interface implementation for reconciler since are not easy to discover. However since this is mainly intended for the extension (quarkus/SB) I think it is better to do this way as it is then having it as a default method on reconciler interface.

What however, might be considered as an alternative ( and let me know this if this is also feasible on Quarkus side), I'm quite sure this would work in SB, but can prepare a prototype; is this:

To not bake this mechanism into the core, rather have this interface in the extensions only, and provide it as a bean:

@Singleton
@ForController(MyController.class)
@ForController(MyOtherController.class)
public class MyConfigOverrode implements ConfigurableReconciler {

@Inject 
Object anyBeanOrRuntimeValue

void updateConfigurationFrom(ControllerConfigurationOverrider configOverrider) {
 // my code to use override, possibly using runtime injected beans.
}

}

Then is bean instance could be easily used with the current API when the reconciler is registered in the background.

Note the @ForController(MyController.class) part. This could be used to identify the controller(s), thus possibly more controllers that share some common values, like label selectors.

Can expand on this later, hope it is clear how I mean it. Pls let me know what do you think. The pros is that we don't have to introduce an other construct to the core, also might be a more flexible approach for the users (maybe with a more modern API? ). On the other hand the config is not tightly coupled with the reconciler (which might be a good and also a bad thing).