Override `namespace` for objects about hull

[gre9ory]

One other caveat I forgot about is the need to seperate non-namespaced objects from namespaced ones to set it only where it belongs: kubernetes-sigs/external-dns#2807

I think I have seen that Kubernetes is not complaining when a namespace is set on a non-namespaced object but better handle this properly from the get go.

[sczech]

The second solution is exactly how we have implemented it in our internal charts. We set .Release.Namespace as default and allow it to be overwritten by .Values.namespaceOverride. I haven't encountered any issues with this implementation (also tried helm install) and big charts like kube-prometheus-stack use it as well (https://github.com/prometheus-community/helm-charts/blob/6db99b756ff91586e26a1d009eceaf9cee8b1c40/charts/kube-prometheus-stack/templates/_helpers.tpl#L124) so I guess it should be fine to always populate metadata.namespace.

[sczech]

I think I would want to put it here:

hull:
  config:
    general:
      metadata:
        namespaceOverride: 

@sczech Do you think there is a usecase for individual namespaceOverride's on the instance level as mentioned before? So the logic on an per instance basis could populate the rendered namespace like so:

1. hull.objects.<type>.<instance>.namespaceOverride if present and non-empty
2. hull.config.metadata.namespaceOverride if present and non-empty
3. .Release.Namespace otherwise

It would be not much extra effort to do so and it should cover all bases.

I don't think there is a need for individual fields since a chart should really only be deployed to one namespace at a time. If you want to deploy to another namespace the preferred solution should be to use subcharts.

Concerning the namespaceOverride key location: I find it to be most intuitive to put it on the same level as nameOverride and fullnameOverride, at least that is where I would look for it first.

[sczech]

Looking good! Thank you for the quick implementation 🙏

[sczech]

Thank you for the quick response! My use case is that we don't install Helm Charts directly into the cluster. We have a deployment pipeline that does a helm template and commits the output into our infrastructure repo. Then the plain manifests are synced from this repo into our Cluster via FluxCD.
This is in line with GitOps best practices and allows us to have a full declarative state of our cluster in Git. But since Helm isn't communicating directly with our cluster we have to define metadata.namespace in advance and bake it into the template.

[gre9ory]

Interesting, never looked at the metadata.namespace when helm templateing so far. Have used helm update/install all the time sofar in our workflows.

When I did a test just now it turns out -n and --namespace does not put a namespace in the templates (exactly as you said above). Quite surprising behavior but I see I am in good company here. One of the things where the donkey work is seemingly unnecessarily handed over to the chart maintainers (adding namespace property to all objects) or users (post-processing templates with whatever tool) 👎

Anyhow, now I totally understand what you are after with your request. Flux is also at the top of my list of things to do next since we want to use it at work too so sounds like a total win-win to allow this. It should also be not much work.

Some questions aligning on the desired implementation:

• I see that (some) people just take the {{ .Release.Namespace }}, ergo the -n passed to helm template, to populate the metadata.namespace fields (like here).

• Others have an extra field in mind like your config.general.namespaceOverride and fallback to the {{ .Release.Namespace }} when not provided as for example here:

  {{- if .Values.namespace -}}
  {{- .Values.namespace -}}
  {{- else -}}
  {{- .Release.Namespace -}}
  {{- end -}}
  

Small question I have whether there is any danger to always setting this metadata.namespace field for the helm upgrade/install use case? Though fairly sure Helm does not complain when encountering a metadata.namespace here in the templates (otherwise there wouldn't be all the examples above) but maybe you can confirm that there is no danger in explicitly populating this field always? If yes then I think I would go with the second approach where it always populates metadata.namespace either from config.general.namespaceOverride or {{ .Release.Namespace }} if config.general.namespaceOverride isn't present or empty.

[gre9ory]

I think I would want to put it here:

hull:
  config:
    general:
      metadata:
        namespaceOverride: 

@sczech Do you think there is a usecase for individual namespaceOverride's on the instance level as mentioned before? So the logic on an per instance basis could populate the rendered namespace like so:

1. hull.objects.<type>.<instance>.namespaceOverride if present and non-empty
2. hull.config.metadata.namespaceOverride if present and non-empty
3. .Release.Namespace otherwise

It would be not much extra effort to do so and it should cover all bases.

[gre9ory]

Ok it is done, new releases with namespaceOverride:

Release 1.27,1
Release 1.26.3
Release 1.25.14

Followed your suggestion so you can use:

hull:
  config:
    general:
      metadata:
        namespaceOverride: abc

to change the namespace in the templates.

If not provided, the {{ .Release.Namespace }} is used.

Hope that works and if you have other problems. feature suggestions or find a bug let me know!