Here's my concern about just adding namespaces to everything without exception:

If I wanted to export into a file tree like {cluster}/{namespace}/{kind}-{name}.yaml, I would find cluster roles under the namespace of their environment instead of under default or maybe `` like I would expect to find them.

The kubernetes API won't complain, but things will not necessarily go into the directories I'd want them to.

Of course we could also work around this by having a set of overlays we put over the k8s jsonnet lib that add the annotation to those constructors as well.

How would this affect an 'environment' with resources across namespaces?

I would ideally like to have a setup like

environments/cluster1/base/
environments/cluster1/myapp-dev1/
environments/cluster1/myapp-dev2/
environments/cluster2/base/
environments/cluster2/myapp-dev3/
lib/myapp/
lib/base/

Where the myapp lib is a collection of resources for an instance of our application and base is our cluster configuration, ingress, logging, metrics etc.

App environments are all under 1 namespace but the cluster baseline is spread across a few.
i don't really want to have to do cluster/base-logging, cluster/base-metrics etc as separate tanka environments, conceptually they're the same thing and i want to apply them all at once.

@hamishforbes this should behave exactly as it did before, at least during apply.

Tanka will only ever set the namespace defined in spec.json, if your resources that come from Jsonnet don't already have one. If they do, Tanka won't touch that (it never did).

Only two differences will be there:

• Cluster-wide resources will show a namespace in YAML, but this will always be discarded by kubectl afterwards. This makes our code much simpler however
• Namespaces will already be present during show or export, so they are actually passed to CD tools like Argo or Flux if needed

I'd rather see Tanka or Kubectl return an error (or at least a warning), expecting the developer/jsonnet to set the namespace instead, depending on Tanka to resolve the namespace promotes negligence imo.

Would it be an option for this behaviour to be configurable?

I think I would prefer to require namespace to be explicitly set and it would be easier to lint/validate in a CI pipeline if Tanka didn't automatically inject namespaces.

@hamishforbes There is already discussion going about about this exact thing internally and I am happy to have this debate more broadly. Could you open a separate issue for this?

Generally spoken, in an attempt to have as few knobs as possible, I am not a fan of configurable things. Instead, we should aim for a solution that works better for everybody.

Also you could join our monthly community call (https://docs.google.com/document/d/1mEsc0GxlnwbWAXzbIP7tBb6T5WgAI66_0gIWJzqB93o) this evening and bring this up!