Nil pointer evaluating interface with custom values file

user_1838556 0
Viewed 919

I'm working on an umbrella chart which has several child charts. On the top level, I have a file values-ext.yaml which contains some values which are used in the child charts.

sql:
  common:
    host: <SQL Server host>
    user: <SQL user>
    pwd: <SQL password>

These settings are read in configmap.yaml of a child chart. In this case, a SQL Server connection string is built up from these settings.

apiVersion: v1
kind: ConfigMap
metadata:
  name: "childchart-config"
  labels:
    app: some-app
    chart: my-child-chart
data:
  ConnectionStrings__DbConnection: Server={{ .Values.sql.common.host }};Database=some-db

I test the chart from the umbrella chart dir like this: helm template --values values-ext.yaml . It gives me this error:

executing "my-project/charts/child-chart/templates/configmap.yaml" at <.Values.sql.common.host>: 
nil pointer evaluating interface {}.host

So, it clearly can't find the values that I want to read from the values-ext.yaml file. I should be able to pass in additional values files like this, right? I also tried with $.Values.sql.common.host but it doesn't seem to matter.

What's wrong here?

kubernetes-helm kubernetes
1 Answers

When the child charts are rendered, their .Values are a subset of the parent chart values. Using $.Values to "escape" the current scope doesn't affect this at all. So within child-chart, .Values in effect refers to what .Values.child-chart would have referred to in the parent.

There's three main things you can do about this:

  1. Move the settings down one level in the YAML file; you'd have to repeat them for each child chart, but they could be used unmodified.

    child-chart:
  sql:
    common: { ... }

  2. Move the settings under a global: key. All of the charts that referenced this value would have to reference .Values.global.sql..., but it would be consistent across the parent and child charts.

    global:
  sql:
    common: { ... }

    ConnectionStrings__DbConnection: Server={{ .Values.global.sql.common.host }};...

  3. Create the ConfigMap in the parent chart and indirectly refer to it in the child charts. It can help to know that all of the charts will be installed as part of the same Helm release, and if you're using the standard {{ .Release.Name }}-{{ .Chart.Name }}-suffix naming pattern, the .Release.Name will be the same in all contexts.

    # in a child chart, that knows it's being included by the parent
env:
  - name: DB_CONNECTION
    valueFrom:
      configMapKeyRef:
        name: '{{ .Release.Name }}-parent-dbconfig'
        key: ConnectionStrings__DbConnection
user_100081730
Related