[question] Inclusion of namespace: {{ .Release.Namespace }} in objects metadata

[glothriel]

Which chart:

prometheus-operator, grafana, but applies to all the charts

Description

In the face of charts/stable deprecation, we are investigating other methods of deploying prometheus-operator and grafana using helm.
In our specific case, we are using helm template to render templates that fully describe our cluster's state in a declarative way, and then we load them to kubernetes using kubectl apply, in a GitOps fashion.
In order for this to work, we need to include information about namespace inside the templates.
One way to do this, is by including

metadata:
    namespace: {{ .Release.Namespace }}

In all namespace-scoped resource definitions. Bitnami charts lack this behavior.

My question is: would you accept PR with this functionality added? It seems that there is no consensus in helm community about how should this be handled, at the moment at least.

[juan131]

Hi @glothriel

Thanks so much for the feedback

I don't see any advantage on adding the namespace to the manifests since helm install --namespace XXX or kubectl apply --namespace XXX will manage the namespace for you.

• Option A) We adapt every chart so you can run:

$ helm template --namespace XXX grafana bitnami/grafana | kubectly apply -

• Option B) We don't adapt any chart, and you run:

$ helm template grafana bitnami/grafana | kubectly apply --namespace XXX -

Honestly I don't see any advantage on using "approach A" vs "approach B"

In our specific case, we are using helm template to render templates that fully describe our cluster's state in a declarative way, and then we load them to kubernetes using kubectl apply, in a GitOps fashion

I understand people was using helm template ... | kubectl apply due to the concerns with Helm 2 and Tiller. But with Helm 3, I don't see the point on doing so. I mean, you can still run your application following a GitOps workflow by cloning the charts repo and running helm install/upgrade my-release /path/to/the/chart.

[glothriel]

you can still run your application following a GitOps workflow by cloning the charts repo and running helm install/upgrade my-release /path/to/the/chart

Theoretically yes, but chart values are the problem here. We generate values from our internal GUI configuration tool. Those values contain secrets, that we don't want to expose anywhere. Our deployment pipeline runs helm template outside of the cluster then uses sealed secrets to encrypt the secrets and pushes everything to git.
This has some nice side effects:

• You have a nice fully declarative, namespaced definition of all your kubernetes resources inside your git tree
• The definition contains secrets, but they are not visible to GitOps controller nor human reviewers

It seems, that Spinnaker also takes similar approach, at least they suggest including the namespace in your charts in their official guide, however they use helm2 atm.

[juan131]

Hi @glothriel

I see the point on using a fully declarative, namespaced definition of all your kubernetes resources. And it's great you're using sealed secrets by the way.

@javsalgar what's you opinion on this?

As a workaround you could use kustomize to adapt the manifests you generate with helm template including the namespace. See:

• https://github.com/kubernetes-sigs/kustomize/blob/master/docs/plugins/builtins.md#namespacetransformer

[glothriel]

Hi @juan131
What's the progress?

We are currently blocked, so we would really appreciate a decision here. There is another helm chart we'd like to use (RabbitMQ) but lack of metadata.namespace blocks us.

[javsalgar]

I'm not sure if I fully understood, but it seems that adding the namespace increases the compatibility with other tools like Spinnaker or other GUI-based tools. Then I see no harm in adding the feature.

[glothriel]

Thanks for the decision guys, from my perspective this ticket can now be closed, as I already know what I wanted to know.

[juan131]

Thank you for the great reasons you gave us to include these changes! Let's close the issue

Please do not hesitate to reopen it if you face issues again with the "namespace" in your manifests.