refactor webconsole controller

[eguzki]

I propose some refactor to follow better reconciliation patterns. Some relevant changes are:

• pkg/controller/webconsole/webconsole_controller.go includes reconciliation logic which leverages inherited BaseReconciler
• Checking consolelink support in the cluster is done in the same way as other CRD's are checked (for instance PodMonitors)
• It aims to be extensible. When we implement consolelink for existing 3scale tenants, they should be easy to be added. They should be added in the main Reconcile method.
• Reconciliation logic is reused and does not need to be re-implemented (DRY).
• Reconciliation is based on the route object triggering reconciliation loop. List of routes is not fetched for every reconciliation loop (which happens for every single route object in the namespace). This change in the followed approach can be discussed. There are pros and cons, but I find it more appropriate for this usecase.
• helper/webconsole only contributes with MasterConsole object definition and mutator. A mutator is what is called when actual reconciliation occurs. When consolelink exists, this is compared with the desired consolelink object and the mutator tells if the existing object needs changes and which changes.

let me know what you think

cc @miguelsorianod

[myeung18]

I propose some refactor to follow better reconciliation patterns. Some relevant changes are:

• pkg/controller/webconsole/webconsole_controller.go includes reconciliation logic which leverages inherited BaseReconciler
• Checking consolelink support in the cluster is done in the same way as other CRD's are checked (for instance PodMonitors)
• It aims to be extensible. When we implement consolelink for existing 3scale tenants, they should be easy to be added. They should be added in the main Reconcile method.
• Reconciliation logic is reused and does not need to be re-implemented (DRY).
• Reconciliation is based on the route object triggering reconciliation loop. List of routes is not fetched for every reconciliation loop (which happens for every single route object in the namespace). This change in the followed approach can be discussed. There are pros and cons, but I find it more appropriate for this usecase.
• helper/webconsole only contributes with MasterConsole object definition and mutator. A mutator is what is called when actual reconciliation occurs. When consolelink exists, this is compared with the desired consolelink object and the mutator tells if the existing object needs changes and which changes.

let me know what you think

cc @miguelsorianod

Thank you for showing me the correct way of doing it.