Epic Goal

The Operator manages all Argo CD workloads, such as API server, repository server, application controller, etc.

Right now, the following workloads are managed:

• argocd-server (API server and UI)
• argocd-repo-server (Repository server)
• argocd-application-controller (Main reconciliation controller)
• argocd-applicationset-controller (ApplicationSet reconciliation controller)
• argocd-redis (volatile cache)
• argocd-dex (SSO)

To support installations with a minimal resource footprint and to distribute installations across clusters or namespaces, we need to be able to only install a partial Argo CD.

We want to let the user chose which of those workloads are to be installed/managed for a given Argo CD instance. Because some of the components have dependencies to each other, we also must give the user the chance to specify the location (URL or FQDN/port combination) of a workload that is running elsewhere, i.e. that has not been installed by the current instance. Currently, these locations are configured automatically by the Operator (for example, the --repo-server parameter for the argocd-application-controller is set automatically to the same instance's repository server).

The following dependencies between the workloads exist:

argocd-application-controller depends on

• argocd-repo-server
• argocd-redis

argocd-server depends on

• argocd-repo-server
• argocd-redis
• argocd-dex (in SSO scenarios)

argocd-applicationset-controller depends on

• argocd-repo-server
• argocd-redis

argocd-repo-server depends on

• argocd-redis

For each of the above components, the user should be specify the location for the appropriate dependency.

Why is this important?

There are two major drivers for this feature:

• To support installations with minimal footprint, e.g. when installing GitOps Operator on Edge devices such as Microshift. These installations typically do not require the API or UI provided by the argocd-server workload and want to utilize Argo CD's "core" mode.
• To support distributed installations, where only the application controller runs on the cluster, and the repository server and other components will run on a different cluster.

The Edge scenario (Microshift) is one of the RHDP priorities right now.

Scenarios

1. ...

Acceptance Criteria (Mandatory)

• Each workload can be enabled/disabled individually per Argo CD instance. The default is to be enabled.
• Where it makes sense, the auto-generated location for a dependency workload can be specified manually by the user. If the location is not specified, the default Operator-generated one should be used:
  • The API server workload can be configured for locations of argocd-repo-server and argocd-redis
  • The Application controller workload can be configured for locations of argocd-repo-server and argocd-redis
  • The Repository server workload can be configured for location of argocd-redis
  • The ApplicationSet controller workload can be configured for locations of argocd-repo-server and argocd-redis

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. ...

Open questions::

1. ...

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment