ArgoCD should only be installed in one cluster.

[nacx]

ArgoCD should only be installed in one cluster, as having one instance per cluster is not the right way to configure it (different installs, users per cluster, etc). Instead, a central ArgoCD installation with proper permissions (using projects, etc), is a much better example of how real-world ArgoCD installations are.

We don't have to go the project and permissions route, but we should at least install ArgoCD in only one cluster and update the existing example applications to use the cluster generator to get them installed in all the registered clusters, preserving the current behaviour.

[smarunich]

count on me for that one, when I hopefully will get cycles to work on it... I wish my December would be different...

[smarunich]

There are challenges with leveraging the applicationset approach across the clouds (i.e. authentication handling, as the constructs are built on the point of "role" assumption). Few references how to:

• argocd-k8s-auth aws command dont have flag for region-code argoproj/argo-cd#11207
• feat: add gke auth command to argocd-k8s-auth (#5958) argoproj/argo-cd#9190
• Kubelogin support in ArgoCD argoproj/argo-cd#9460

Basically or we should static auth credentials (which is impossible) or keep the deployment within the common cloud (which is not a common demo example), i.e. we will hit the challenges when k8s where ArgoCD will be installed... needs to call out another cloud fleet.

Talking fluxcd

https://fluxcd.io/flux/get-started/#multi-cluster-setup

To use Flux to manage more than one cluster or promote deployments from staging to production, take a look at the two approaches in the repositories listed below.

https://github.com/fluxcd/flux2-kustomize-helm-example
https://github.com/fluxcd/flux2-multi-tenancy

Interesting enough, however not necessary demo centric at this stage is fleet https://fleet.rancher.io/concepts - I will dig deeper on that one...

p.s. as meanwhile as much as I want it feels like argocd or fluxcd cannot be yet deployed in a centralized fashion... which leads to the point of doing wrappers around which apps do go to which clusters... #177 (comment)

[smarunich]

https://openunison.github.io