Making sure that controller dont reconcile with multiple CR

[Jaydipkumar Arvindbhai Gabani]

Right now, the controller has strict requirements on only one instance of operatorConfig. However, to make sure changing this nature in the future if needed don't result in it changing a lot of code and approach, we should allow a way to have more than one instance and create a resource that has ways to separate resource from one operatorConfig resource to another. Make use of predicate filters to tell requests apart and enqueue in the one we are interested in reconciling.

I think in order to achieve the requirement of not reconciling on more than 1 resource, I think we should use a predicate to filter out all the events.

So two fold recommendation:

assume that there could be more than 1 instance and create resources that have ways to separate resources from one instance to another
add a predicate filter to not enqueue a request apart from a specific one we are interested in reconciling.

[Jaydipkumar Arvindbhai Gabani]

this will need a little planning as well because I am not clear on what resources could be shared and what resources should be CR-dependent.

For example, proxy and UI could be shared but cluster tasks should be owned by only one operatorConfig CR?

What would be the motivation behind having multiple operatorConfig CRs?

[Alay Patel]

What would be the motivation behind having multiple operatorConfig CRs?

could be multiple:

For example, assume we need to have a separate installation from Kubernetes->OpenShift, we add a type: field in the CR spec and allow for two CRs. The OpenShift type will continue to run the existing logic, the Kubernetes type will create resources required for that kind of migration

1. I think the essential concept is: reconcilers should not assume that it is only reconciling 1 object even though it is a requirement at the current moment.
2. All the code of the controller, should ideally scale up well if we loosen this restriction.