doe1331
doe1331

Reputation: 181

helm getting subchart service names

Whats the best way to get the helm subchart service names to reference into my ingress controller that will sit in the parent chart

values.yaml
---
ingress:
  paths:
    - serviceName: app-1
      path: /app-1/*
      port: 8080
    - serviceName: app-2
      path: /app-2/*
      port: 8080


ingress.yaml 
---
{{- range .Values.ingress.paths }}
          - path: {{ .path }}
            backend:
              {{- $subchart := .serviceName -}}
              serviceName: {{- include "$subchart.fullname" .}}
              servicePort: {{ .port }}
        {{- end }}

template: no template "$subchart.fullname" associated with template "gotpl"

Upvotes: 16

Views: 12590

Answers (5)

amao
amao

Reputation: 91

helm 3.7 version has solved the problem https://github.com/helm/helm/pull/9957.
You can use like this

{{ template "bar.fullname" .Subcharts.bar }}

Upvotes: 9

fnkr
fnkr

Reputation: 10075

If the subchart uses the fullname function from _helpers.tpl (provided by helm by default for new charts) you can use this (replace postgresql with the name of the subchart):

{{- $fullName := include "postgresql.fullname" (mustMerge (dict "Chart" (dict "Name" "postgresql") "Values" .Values.postgresql) (deepCopy .)) -}}

Upvotes: 1

I have found that the best way to reference a service name is to override the template that they are using. There are some caveats to doing this however.

  1. The subchart and your chart will have different contexts so they will most likely render the template differently
  2. There are some things that are only available to the subchart

Most charts have a template similar to the one below in their _helpers.tpl file.

{{/*
Create a default fully qualified app name.
We truncate at 63 chars because some Kubernetes name fields are limited to this (by the DNS naming spec).
If release name contains chart name it will be used as a full name.
*/}}
{{- define "newchart.fullname" -}} 
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- if contains $name .Release.Name }}
{{- .Release.Name | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}
{{- end }}

The subchart has different .Values to your chart. We will fix this when we render this template by creating a context that is similar to the subcharts context.

Instead of calling it with the . context we create a new context by replacing the .Values with the subcharts .Values.

{{ template "newchart.fullname" (set (deepCopy .) "Values" .Values.newchart }}

We use deepCopy so that we don't actually change the . context but rather create a new one to use.

The subchart has access to its own .Chart values that we can't replicate. In this case we will have to hardcode the value of .Chart.Name to the template. In this we can just replace it with the chart name newchart.

Once we have done this both nameOverride and fullnameOverride on the subchart will work without you having to manually change anything in your template files.

Upvotes: 2

Thomas Decaux
Thomas Decaux

Reputation: 22681

It depends on the sub-chart definition!

As an example, elasticsearch chart, see here https://github.com/elastic/helm-charts/blob/master/elasticsearch/templates/service.yaml, is defining 2 services.

Both services name can be declared as value clusterName.

Upvotes: 0

How about hardcoded subchart name scoped by release ?

{{ .Release.Name }}-<subchart_name>

Upvotes: 3

Related Questions