Allow setting application namespace from ApplicationSet template

[waaghals]

Summary

With the introduction of namespaced applications in #9755 we can have applications in different namespaces.
But the applications generated from an ApplicationSet always use the namespace from the ApplicationSet.

ApplicationSet should allow setting .spec.template.metadata.namespace for the generated application.

Motivation

When deploying the same repository/directory to multiple clusters, one could use ApplicationSets to automatically generate applications for each cluster.
The names of these applications can become rather large as they might include both the application name and cluster name.

For organization purposes it might make sense to put all these argo-cd applications for the same repositry/directory into a single namespace.

Lets imagine the following directory structure:

• /cluster-1/cert-manager
• /cluster-1/external-dns
• /cluster-2/cert-manager
• /cluster-2/external-dns
• /cluster-3/cert-manager
• /cluster-3/external-dns

With the following ApplicationSet

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: applications
  namespace: argocd
spec:
  generators:
  - git:
      repoURL: ...
      revision: main
      directories:
      - path: **/*
  template:
    metadata:
      name: '{{path[0]}}'
      namespace: '{{path[1]}}' # this is currently not used, it always uses namespace of set
    spec:
      project: default
      source:
        repoURL: ...
        targetRevision: main
        path: '{{path}}'
      destination:
        name: '{{path[0]}}'
        namespace: '{{path[1]}}'

Which I would expect to generate applications like:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cluster-1
  namespace: cert-manager
spec:
  project: default
  source:
    repoURL: ...
    targetRevision: main
    path: ...
  destination:
    name: cluster-1
    namespace: cert-manager

Proposal

When .spec.template.metadata.namespace is set on the ApplicationSet, use that, otherwise fallback to the ApplicationSet's namespace.

[rishabh625]

Hi , assigning this to myself , would soon submit the change

[ONordander]

Hey.
@rishabh625 any updates on this?
Really looking forward for this to be added.

[crenshaw-dev]

I think we should consider having the ApplicationSet controller enforce constraints on the namespace field.

For example, ApplicationSets in namespaces matching dev-* may only create apps in that same namespace. This would allow non-admin users to safely create ApplicationSets in a restricted namespace or namespaces.

But of course, there should also be a mode allowing an ApplicationSet to deploy to multiple destination namespaces. And ideally a way to enforce both options with the same controller.

Are folks considering more advanced use cases which we should consider?

[rishabh625]

Hey. @rishabh625 any updates on this? Really looking forward for this to be added.

working on it.

[marshell0]

Any update? or which version will include this fix?

[crenshaw-dev]

This does what I wanted (appset in any namespace, deploying to same namespace): #12378

I think it's distinct from this request, which is an appset deploying to other namespaces. I think both are valid.

[callppatel]

When this fix will be available?

[via-justa]

Is there any update on that?

[reedjosh]

Bump, would love this feature.

[mirza-src]

any updates on this? Really want this feature

[crenshaw-dev]

imo we need a proposal for an AppSetProject feature in order to make this request viable.

The whole point of the apps-in-any-namespace feature is to enable gitops-based self-service of applications for non-admins. Appset-within-a-namespace allows safe self-service of appsets within user-controlled namespaces.

But appsets-spanning-namespaces again makes the AppSet effectively an admin resource. If I can create an AppSet that can install an App in any namespace, I can install an app in the namespace holding admin-level apps (usually the argocd namespace) and gain the level of access associated with that namespace.

To make an appsets-spanning-namespaces feature usable, we need some way for admins to restrict what their users' AppSets can do. Examples of restrictions they may need:

1. Which namespaces the AppSets may be installed in
2. Which namespace the AppSet may install Apps in
3. Which projects the AppSet's generated Apps may use
4. Which SCM APIs the AppSet's PR and SCM generators may access

We would need to decide how the currently pseudo-project-scoped AppSet resource would be handled by the API server in a system which includes an AppSetProject.

This is a very, very big feature and would require a proposal to be presented and accepted.

Is anyone up for writing the proposal?

[mate4st]

Interesting, our use case differs that we do not care about self service, but having a namespace per cluster with its applications purely for organizational purposes. This basically prevents us to use ApplicationSets as we would than need to put all applications in one namespace.

Additionally I wonder, aren't ApplicationSet's considered to be an "admin" resource for other reasons anyway?