Helm chart templates are missing the namespace

[ankitm123]

I recently migrated from kustomize to helm charts for metallb. While the kutomize manifests had namespace (

metallb/config/native/kustomization.yaml

Line 10 in e708fc9

namespace: metallb-system

), the helm chart templates are missing namespaces for namespace scoped resources when generating manifests using helm templates (We generate manifests using helm and then apply using kubectl).
For example:

metallb/charts/metallb/templates/rbac.yaml

Lines 109 to 111 in e708fc9

	metadata:
	name: {{ include "metallb.fullname" . }}-controller
	labels: {{- include "metallb.labels" . | nindent 4 }}

[gclawes]

Helm templates typically don't render namespaces, helm will inject that at deploy time with helm install or helm upgrade. I believe it's typically considered an anti-pattern in chart development to include the .metadata.namespace in the templates.

If you are not using helm to do the install, you can do something like helm template ... | kubectl apply -n <namespace>

[ankitm123]

Helm templates typically don't render namespaces

Not sure about this.
See argoproj/argo-helm#1937 (comment). I see almost all major projects specify that. Also in the PR, I am using .Release.namespace, a value that is injected by helm anyways (https://helm.sh/docs/chart_template_guide/builtin_objects/) 🤔

believe it's typically considered an anti-pattern in chart development to include the .metadata.namespace in the templates.

Any references for this? I don't see anything in the helm best practices (https://helm.sh/docs/chart_best_practices/) unless I am missing context. Probably this helm issue is what ur referring to. helm/helm#3553, but in all honestly it seems more like a flaw with helm 🤷

If you are not using helm to do the install, you can do something like helm template ... | kubectl apply -n

Yes, that would work, but I think the point of helm template is so that other tools (could be kubectl, but also other tools which dont have a way to specify the namespace) use helm generated templates. A comment from argo: argoproj/argo-helm#1937 (comment)

I can try to work around this with some yq (In case we move away from kubectl to some other tool), if you think it is not worth including the namespace in the templates.

[fedepaol]

I am also thinking that the operator, which uses the helm templates, would benefit from this (we currently set the ns explicitly in code after generating the object).

Need to read all the provided references before I can have an opinion on wether this is acceptable or not.
Will get back!

[brnl]

Interesting issue. I believe, but feel free to burn me, that using the --namespace metallb-system parameter, optionally combined with --create-namespace installs MetalLB in the desired namespace. Wouldn't that fix this issue?

[ankitm123]

Interesting issue. I believe, but feel free to burn me, that using the --namespace metallb-system parameter, optionally combined with --create-namespace installs MetalLB in the desired namespace. Wouldn't that fix this issue?

Not when using helm template. See: helm/helm#3553
@fedepaol any updates?

[fedepaol]

Sorry for the late reply.
I was not able to find real evidence for this to be a bad practice. Also, a good amount of authorative projects (see argoproj/argo-helm#1937 (comment) for example) are using this, and by leveraging it we wouldn't need to hack the namespace into the resources in the operator, as we do today.