This Jira issue reflects the GitHub discussion here: https://github.com/openshift/cluster-ingress-operator/pull/1152#discussion_r1996105264

Currently, cluster-ingress-operator's gatewayclass controller has these responsibilities:

• Watch gatewayclasses.
• If a gatewayclass that has our controller name is observed, then do the following:
  • Create a subscription to install OSSM.
  • Create an Istio CR. (Currently, this generates error messages while the controller tries to create the CR before OSSM has created the CRD. However, the CR creation eventually succeeds, so the controller achieves its goal, albeit noisily.)
  • Start watching istios in order to be able to update the operator's Istio CR if it is updated or deleted.

This makes the controller a bit fraught with responsibilities and requires the unusual behavior of using a sync.Once object to start a watch from within the controller's reconcile loop.

Additionally, cluster-ingress-operator's gatewayapi controller has these responsibilities:

• Watch featuregates and CRDs.
• If our featuregate is enabled, then do the following:
  • Create or update the Gateway API CRDs if the expected ones are not installed.
  • Start controllers that require the Gateway API CRDs.

Note that the featuregate logic is a holdover from earlier iterations of the operator. In the current design, checking the featuregate in the controller is redundant as the operator checks featuregates when it starts and terminates (causing the operator to restart and re-initialize) if the set of enabled featuregates changes.

Instead, these controllers could be refactored into the following set of controllers:

• A controller that would watch CRDs, create or update them if the expected ones were not installed, and start dependent controllers. (This could be two separate controllers: one to create and update CRDs and one to start controllers.)
• A controller that would watch gatewayclasses and subscriptions and create or update the subscription as needed. This controller would be started by the first controller after it installed the Gateway API CRDs.
• A controller to watch istios and create and update the operator's Istio CR. This controller would be started by the first controller after OSSM installed the Istio CRD.

This refactoring would have the following benefits:

• Each controller becomes simpler, easier to read, and less likely to have defects.
• The refectoring obviates the unusual behavior of using sync.Once to start a watch from a reconcile loop.
• Vestigial featuregate logic is removed.
• The controller that creates the Istio CR doesn't run until the Istio CRD is ready, thereby avoiding unnecessary reconciliations and creation failures in the logs.