Background:

Currently, we plan to package the argocd-agent addon for ACM by collecting all of the installation manifests and wrapping them in an AddonTemplate CRD. Because the argocd-agent project is under rapid development and we lack resources in ACM workload-management team, this approach is error prone and difficult to maintain.

The good news is the GitOps team has enhanced the existing argocd-operator/gitops-operator to deploy both the hub/principal and spoke/agent (soon) components of the argocd-agent. We already have an ACM gitops-addon that simply wraps this operator to install the core argocd components to the spoke for our ACM pull model.

Problem with creating a brand new ACM argocd-agent addon:

• Duplicating effort by building a separate addon when we already have a gitops-addon.
• High maintenance burden as the argocd-agent constantly evolve.
• Lack of resources to continuously update the new addon.

Proposed Solution:

Instead of creating a new addon, extend the existing ACM gitops-addon so that it can continues to manage deployment of the argocd core components. But adds support for installing the argocd-agent components via the operator as well. By leveraging the operator's built-in capabilities, we minimize manual development upkeep and align with the GitOps team's roadmap.

Goal:

Complete the upstream work to adjust the ACM gitops-addon to leverage the argocd-operator/gitops-operator for argocd-agent deployment, reducing maintenance overhead and ensuring compatibility with future argocd-agent project development.

References:

• https://redhat-internal.slack.com/archives/C01RQH8KQ87/p1753341344847219
• https://github.com/argoproj-labs/argocd-agent/pull/482 - argocd-agent PR still not merged yet
• https://github.com/argoproj-labs/argocd-operator/blob/master/controllers/argocdagent/docs/quickstart.md - super rough development only guide