When specifying a kube config context, support the entire context including the namespace

[Toady00]

The kube config file context supports a namespace component. When using the kubectl cli directly, any resource that doesn't explicitly have a namespace set uses the namespace assigned in the context itself. It was surprising when I used that same context with the kube provider for the first time and it ignores the context set namespace. I found a feature request to allow setting the default namespace at the provider config level, and the response was it was asked for a couple of times but the preference was for the namespace to be set explicitly. There was concern about brittleness and confusion. I would like to provide a different view.

He have multiple different namespaces that should all be very similar. We have a namespace specific tfvars file that's name matches the context in the kube config. From an automation standpoint I can just run something like:

NAMESPACE=foo
TF_VAR_kube_context=$NAMESPACE terraform apply --var-file ${NAMESPACE}.tfvars --auto-aprove

And know that each namespace matches. Having to specify the namespace, even if using a single variable to do so, in each resource isn't very DRY, and can easily be missed by PR reviews. Our RBAC is setup to where we can't create anything in the default namespace from the pipelines, so at least on this project we just get a failure instead of the potential of rogue resources being deployed to the default namespace. But for anyone on-boarding that has kube experience and is new to the kube provider, this is jarring behavior. It isn't what one would expect.

I think ignoring this feels more like a bug and increases the confusion in scenarios where multiple namespaces aren't being used. I think anyone that wants to set a default namespace in one fashion or another should be responsible for that decision. If it could increase brittleness and confusion in multi namespace setups, then the authors of that terraform should be aware of that and know their tooling. If it provides benefit then why not allow us the option when it is warranted?

Not trying to be difficult, just trying to provide an alternative point of view.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment