Goal

Configurations of the GitOps operator are scattered across various CRs and are not inconsistent and unintuitive across various configurations of the operator. They are not aligned with other operators on OpenShift which expose a single CR for the purpose of configuring the operator behavior which causes confusion for admins since they'd expect a similar mechanism for configuring GitOps operator.

Examples of these configurations are:

• Disabling default Argo CD instance: set DISABLE_DEFAULT_ARGOCD_INSTANCE = true on the Subscription CR
• Running GitOps operator on infra nodes: add runOnInfra: true to the GitOpsService CR
• Disabling Dex: set DISABLE_DEX env var on the Subscription CR.
• Custom roles: set CONTROLLER_CLUSTER_ROLE and SERVER_CLUSTER_ROLE env vars on Subscription CR

Here is an example that could be an alternative to the above:

  kind: GitOpsConfig
  metadata: 
    name: config
  spec: 
    disableDefaultArgoCDInstance: false
    nodeSelector: infra
    disableDex: true
    controllerClusterRole: bla
    serverClusterRole: bla

Acceptance Criteria

• A single CR is exposed for all existing configurations related to OpenShift GitOps and a placeholder for future configurations

Related Work

Here are some of the configurations exposed by other operators through their respective config CRs:

• OpenShift Pipelines configurations
  https://tekton.dev/docs/operator/tektonconfig/
• Build configurations
  https://docs.openshift.com/container-platform/4.9/cicd/builds/build-configuration.html
• Console configurations
  https://docs.openshift.com/container-platform/4.9/web_console/configuring-web-console.html#configuring-web-console
• Serverless configurations
  https://github.com/knative/operator/blob/main/docs/configuration.md