Simplify namespaces in Tanka

[sh0rez]

Currently, party defers namespace handling to kubectl. This means the spec.namespace set in spec.json is set as the default namespace during run for the used context, by injecting a custom YAML snippet into $KUBECONFIG. This is a hack.
The big downside is that namespaces are different during show and apply. YAML won't include full namespace information, which is a challenge for export and CD.

Previously we took a more naive approach, where we always injected the namespace, regardless of whether an object actually needs / accepts one. This also led to errors on pseudo types like List objects.

As part of #306, List types won't exist at the time we inject namespaces anymore, as they were unwrapped already. This should allow us to revert back to the naive behaviour, so that export also includes namespace data.

Although we are not aware of any kinds this causes problems with, I also suggest introducing a tanka.dev/namespaced annotation, to manually override the behaviour if required.

[issue-label-bot]

Issue-Label Bot is automatically applying the label kind/feature to this issue, with a confidence of 0.79. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[captncraig]

I like simplicity. We should still make a token effort to not put namespaces on cluster wide objects. But there are not very many of those. A simple list will probably suffice.

So to summarize:

1. If there is a 'tanka.dev/namespaced' label, tanka will honor it. (You should really only need to set that on cluster wide objects).
2. If the type is in our hard coded list of cluster types, do nothing.
3. Otherwise, assume it is namespaced and add the namespace.

It might make sense for tanka to then remove the namespaced label if it finds it. Then if you have a library for a crd (or maybe even the main k8s lib) you can put the label in with the constructor and it will have the right effect without altering the final objects. Just an idea.

The list of types can probably be simpler than the generated store the other or uses. I think our full config really only uses 3 or 4 global kinds.

[sh0rez]

@captncraig I'd suggest an annotation instead of a label, as annotations can have bool values.

Apart from that, I am not sure if it's worth maintaining a list, if kubectl (or even the apiServer?) ignores such data anyways.

After all, all objects seem to include ObjectMeta, so their schema accepts metadata.namespace, even though their implementation doesn't honor the info, right?

[malcolmholmes]

If we don't want a preset list of cluster wide objects inside Tanka, could we create a 'cluster-wide mixin' for k.libsonnet?

k.libsonnet remains Tanka agnostic, but `local k = (import 'k.libsonnet')+(import 'k-tanka-mixin.libsonnet') produces you a Kubernetes library that automatically puts annotations on objects. This library could potentially do a heap of other Tanka specific things.

[captncraig]

I can get behind the library idea. Would such a thing live in jsonnet-libs/k8s or in tanka?