Argo-cd: Question: How can I control Applications defined in other namespaces?

[evgf]

The default ArgoCD deployment maintains all Application objects in the argocd namespace. I can create Applications in other namespaces but they are not recognized by ArgoCD.
Is this a philosophy limitation or I'm just missing something (aka blind)?
If I don't, how should the multi-tenant environments work? Separate ArgoCD?
Kind Regards,

[alexec]

In short, I'm afraid you cannot. Argo CD only listens to apps created in it's own namespace: argocd. This is entirely intentional. Consider the costs of listening to many namespaces for changes, or how you'd reliability do HA/DR.

[alexmt]

Just, want to clarify that argocd namespace is not hardcoded. Argo CD list apps from the same namespaces where it is installed.

[evgf]

Thank you!

[rosscdh]

I might humbly ask for a +1 on this request.
perhaps some kind of namespace whitelist, to limit the impact.

[rosscdh]

I guess one could allow devs to deploy only applications into the argocd namespace.. blacklist all other resources.. but feels.. clunky

[erwbgy]

In short, I'm afraid you cannot. Argo CD only listens to apps created in it's own namespace: argocd. This is entirely intentional. Consider the costs of listening to many namespaces for changes, or how you'd reliability do HA/DR.

Ingress controllers like Contour, Traefik or Nginx listen for resources in all Namespaces without any issue, so this seems like a spurious argument to me. What are the concerns around HA/DR?

[george-angel]

I would like to add our voice to the issue and request this feature. With current design, our development process has oddities we would like to get rid of.

Our setup is:

• argocd namespace that contains ArgoCD Deployment and "Application" definitions for all namespaces we manage with this instance
• a number of other namespaces with business applications, lets call them "business-ns-a" and "business-ns-b"

When a developer is working on a namespace to test or roll-out complex changes, we disable sync for that namespace.

In current design this requires two commands:

$ argocd app set argocd --sync-policy=none
$ argocd app set business-ns-a --sync-policy=none

which is not great having to remember and not intuitive. But also introduces the problem that when a developer wants to re-enable sync after their work is done, with:

$ argocd app set argocd --sync-policy=automated

This re-enables sync for all namespaces, and might impact other developers working on the same cluster.

Being able to have "Application" for "business-ns-a" live in "business-ns-a" - means that sync can be turned "on" and "off" without impacting anything else.

To reduce the scope of namespaces ArgoCD needs to watch, I would suggest having a configurable namespace whitelist on the ArgoCD instance.