How can you call a helm 'helper' template from a subchart with the correct context?

Question

Helm charts define helper templates in _helpers.tpl which are used to create normalized names for the services. The standard form of the template for a service (DNS

Answer 1

Well this is something that isn't very straight forward somehow.

I think what is going on here are the practices helm follows and what is possible with the templates.

One practice is "charts work out of the box" - so whether its a sub-chart or standalone, it should just work. This has some consequences on what you need to configure to properly namespace the resources you deploy and that are referenced.

I had a very similar issue, see How to reference a value defined in a template in a sub-chart in helm for kubernetes?

My "solution" to this is to re-define the postgres.fullname in my own _helpers.tpl:

{{- define "postgresql.fullname" -}}
{{- $name := printf "%s-%s" .Values.global.appId .Values.global.fkNameId -}}
{{- printf "%s-%s" $name "postgresql" | trunc 63 | trimSuffix "-" -}}
{{- end -}}

Since release names must be unique per tiller installation - and we have one tiller in the cluster - I sort of took some distance from using the release name as part of the references and and own naming convention.

The defines in the templates are global. So you could just use those if you're good with the release name prefix that defaults the postgres chart:

{{- define "postgresql.fullname" -}}
{{- $name := printf "%s-%s" .Values.global.appId .Values.global.fkNameId -}}
{{- printf "%s-%s" $name "postgresql" | trunc 63 | trimSuffix "-" -}}
{{- end -}}

I could not come up with release names that would not duplicate service names ("webshop-service-webshop-service") so I tend to not use them since I need them per namespace, not per tiller instance.

Once I define the name from the sub-chart I reference it in my services. I'm ok with it since I know what chart I reference and what it uses for namings. But its true: should I upgrade the sub-chart I need to check if the names are still the same. But since that "fullname" is quite common I think I'm good. And some tests would fail anyway.

But not a beautiful "solution".

Not an answer - just good enough for me :)

Answer 2

I'm very green with Helm so I could be spouting bad practice (though I don't think so). From what I understand a named template is available globally to all parent and subcharts. This is not true however, for values. Parent values are not accessible to a sub chart but subchart values can be accessed by a parent.

Quoted from https://docs.helm.sh/chart_template_guide/#declaring-and-using-templates-with-define-and-template ...

"There is one really important detail to keep in mind when naming templates: template names are global. If you declare two templates with the same name, whichever one is loaded last will be the one used. Because templates in subcharts are compiled together with top-level templates, you should be careful to name your templates with chart-specific names."

Reference:
https://docs.helm.sh/chart_template_guide/#named-templates https://docs.helm.sh/chart_template_guide/#subcharts-and-global-values

Answer 3

I wrote an issue helm/helm#4535 that summarizes the status-quo and proposes an enhancement to Helm which will solve this case.

For anyone looking for an interim solution, I wrote (see my follow-up comment for details) a meta-template that calls any given template in an "ersatz" subchart's scope. It works by synthesizing a dot-object. It is not perfect (not all fields are synthesized), but it will do:

{{- define "call-nested" }}
{{- $dot := index . 0 }}
{{- $subchart := index . 1 }}
{{- $template := index . 2 }}
{{- include $template (dict "Chart" (dict "Name" $subchart) "Values" (index $dot.Values $subchart) "Release" $dot.Release "Capabilities" $dot.Capabilities) }}
{{- end }}

Usage (to call a redis.fullname template of a redis subchart):

{{ include "call-nested" (list . "redis" "redis.fullname") }}