Is it possible to deploy the agent via push-based, then have it turn on pull-based?

[shearn89]

Hi team 👋🏻

I'm looking at setting up a kind of Argo-of-Argos for our clusters, where I would use 1 instance to deploy Argo onto other instances (which would then deploy our apps etc).

Scale is going to become an issue at some point - and the Agent sounds perfect. However, I'm curious how I could get the Agent onto the cluster without having to manually deploy it somehow.

Is it possible to use the "parent" argo instance to deploy the agent and then have the Agent do that flips the cluster into pull-based mode? Or even have a post-upgrade/post-install hook or something that would do so?

At the moment we deploy Argo and other bits with Terraform, which I don't enjoy. If I can avoid having to drop anything onto the cluster except via a central Argo instance (to bootstrap it's own Argo instance), that's ideal!

[poxelyric]

You can also use ocm to deploy the agent

I also have a similar use case. We are currently deploying argocd in core installation from our central argo to many clusters. Within the application that deploys argocd we also deploy application resources that the spoke/data-plane argo then manages.

It seems like the main problem here is that the hub/control-plane argo is supposed to be deployed without an application-conntroller so that it does not try to manage the application CRs on the hub. One workaround could be to deploy two argocd instances on the hub cluster, one for deploying in traditional form (to deploy the agent and argocd) and one for day2 without application controller.

Another workarround can be to deploy a single argo on the hub where the application-controller is specified with a different --application-namespaces parameter than the argocd-server (ui) and the principal. So the application controller should be scoped to the argocd namespace, the ui to both argocd and agent namespaces, and the principal to only the agent namespaces. This way, applications deployed in argocd namespace would be traditional, and applications in agent namespaces can work in agent modes. Buuuuuut you need to create two clusters in argo for every actual cluster, one to direct to the principal resource-proxy and one to direct to the actual cluster api with proper credentials.

Argocd also has an annotation to make the application-controller ignore an application argocd.argoproj.io/skip-reconcile: "true" but as for 0.4.1 it seems to get synced to the spoke cluster, which means the spoke argocd won't sync it either.

[mikeshng]

Argocd also has an annotation to make the application-controller ignore an application argocd.argoproj.io/skip-reconcile: "true" but as for 0.4.1 it seems to get synced to the spoke cluster, which means the spoke argocd won't sync it either.

Nice find! What is your use case exactly with the skip reconcilation? Should we open up an issue for this one? WDYT?

[jannfis]

Another workarround can be to deploy a single argo on the hub where the application-controller is specified with a different --application-namespaces parameter than the argocd-server (ui) and the principal. So the application controller should be scoped to the argocd namespace, the ui to both argocd and agent namespaces, and the principal to only the agent namespaces.

Yes, I think this is a good idea for managing the control plane cluster itself. There are some considerations here (i.e. the redis-proxy), but I wouldn't encourage any multi-cluster management using this application controller instance. You basically lose a lot of the advantages that you get with the agent model. And some of your clusters might not even be reachable from the control plane (either firewalled APIs, NAT setups, etc).

Bootstrapping and lifecycle management is a problem that we likely not want to solve within the argocd-agent project itself. Solutions like ocm-io are much better suited for that.

However, if you solve bootstrapping, there is no reason that would stop you from managing argocd-agent and Argo CD lifecycle on the spokes using the argocd-agent model, just as you would in a classical Argo CD setup.