Add the ability to add annotations to all automatically created namespaces

[insanemal]

Summary

Currently Argo CD can automatically create namespaces. We use Rancher UI. These namespaces do not have the RancherUI annotation for Rancher Projects. It would be nice to be able to define on the Project or even application level annotations that get added to automatically created Namespaces.

Motivation

When using ArgoCD and Rancher UI

Proposal

I think it could be a project level mapping. That way you could map Argo Projects to Rancher Projects. But possibly with App level overrides. It is really about annotating the namespace.

[KarstenSiemer]

Any update or workarounds for this? This is a great feature and this is the somewhat first question you ask yourself when using it. Especially because kustomize removed the ability to add pre- and suffixes to namespaces.

[insanemal]

Yeah, it's still an issue for us. It would be super great for other reasons as well. Using Filebeat/Logstash being able to set project wide annotations is also a boon.

[renaudguerin]

Also in need of this to add a GCP Config Connector annotation to each app's namespace.

[KarstenSiemer]

@jessesuen what do you think about this feature? Would it make sense?
If so, lets think about how we could implement it and I'll try to create a pr for it.

I guess that, since the creating of the namespace is controlled in the sync options, the namespace labels should be controlled there, too. This would be somewhat convenient but would force us to change other features too, since syncOptions is an array.
but anything else would make the CRD too complicated imo. Also adding the ability to add annotations as well would make sense.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: foo
  namespace: argocd
spec:
  destination:
    namespace: bar
  syncPolicy:
    syncOptions:
      createNamespace:
        enabled: true
        labels:
          io.foo.bar/this: labelValue
          io.foo.bar/that: labelValue
      validate:
        enabled: false

But changing the crd this way is a breaking change and a lot of work, which is crazy for such a small feature.
We could however add a new field like:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: foo
  namespace: argocd
spec:
  destination:
    namespace: bar
    createNamespace:
      labels:
        io.foo.bar/this: labelValue
        io.foo.bar/that: labelValue
  syncPolicy:
    syncOptions:
    - Validate=false

This would also make sense to place it directly next to the namespace name it would create. But it still looks a bit confusing.
Just using "labels" and ommiting the createNamespace would be a bad choice imo, since it could create the impression that argocd will always add the labels to the destination namespace and not only to namespaces it creates for this app.

[whyman]

👍 From us too, for External Secrets key name restrictions

[mcorbin]

I'm also interested by this feature (I can also probably find some time to work on it).
A lot of tools rely on labels or annotations on namespaces and implementing this would I think help a lot of people.

[rishabh625]

Instead of adding it as feature, just committing those namespaces in git with required annotations and creating application to manage it wouldn't be enough?

[insanemal]

If that were enough would we be here?

[rishabh625]

I would like to volunteer for contributing to this feature if no one else is working

[crenshaw-dev]

@insanemal how would you feel about this?

- CreateNamespaceLabels=io.foo.bar/this=labelValue,io.foo.bar/that=labelValue

I like @KarstenSiemer's suggestion to add new fields, but those are big (breaking?) changes. Might be a good idea for v3.0.

@ashutosh16 want to see if you have time to work on this?

[insanemal]

I need annotations not Labels. But the syntax is good

[ashutosh16]

I'm thinking to add the annotation to the createnamespace sync option itself.

CreateNamespace=true,io.foo.bar/this=x

I made the code change and tested it in local. I'm able to create a namespace with/without annotation. Do we still need a separate sync option?

[crenshaw-dev]

@ashutosh16 I think we'll probably want to provide the option to accept the labels/annotations JSON-encoded so people are free to include and = or , in their config. Like this:

- 'CreateNamespaceAnnotations={"io.foo.bar/this": "x"}'

[leoluz]

Instead of adding it as feature, just committing those namespaces in git with required annotations and creating application to manage it wouldn't be enough?

@insanemal can you please elaborate on why @rishabh625 suggestion above doesn't satisfy your use-case? I don't use Rancher UI but would like to understand the implications a bit better.

[crenshaw-dev]

Reasons for CreateNamespace, per the original issue thread:

• Using external Helm charts that might not come with their own namespace; you'd have to create a second app for the namespace - Automatically create namespace with application #1809 (comment)
• If a presync hook depends on the ns, you have to create it in the presync hook; afaik this isn't a huge burden, just a bit more complexity - Automatically create namespace with application #1809 (comment)

Not sure if either of these applies to @insanemal.

[crenshaw-dev]

@leoluz some additional use cases are described in similar PRs here:

• Add default ArgoCD label to auto created namespaces #6215
• Add ability to create custom labels for namespaces created with syncOptions CreateNamespace #7799