template-chart: das env-Beispiel zeigt auf eine ConfigMap, die der Chart nicht anlegt #10

New Issue

2026-09-16T16:03:25+02:00

jlab-bot commented

2026-09-16 16:03:25 +02:00

Migriert aus jk-cluster/helm-charts#184 — urspruenglich angelegt von jk-cluster-bot am 2026-08-28.

Verweise der Form #123 im folgenden Text beziehen sich auf die GitHub-Nummerierung, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar.

Das env-Beispiel in template-chart/values.yaml verweist auf eine ConfigMap, die der Chart unter diesem Namen nicht anlegt. Wer den Chart kopiert und das Beispiel stehen lässt, bekommt einen Pod, der nicht startet.

Belegt

template-chart/values.yaml, Zeilen 109–113:

    - name: ENV_FROM_CONFIGMAP
      valueFrom:
        configMapKeyRef:
          name: "{{ .Release.Name }}-{{ .Chart.Name }}-config-map"
          key: "configMapKey"

template-chart/templates/xxx.configmap.yaml, Zeile 4:

  name: "{{ .Release.Name }}-{{ .Chart.Name }}-configmap"

config-map gegen configmap. Das Beispiel zeigt ins Leere.

Auswirkung

Kein ausgelieferter Chart ist betroffen. Gegengeprüft über alle */values.yaml auf origin/main: der Treffer existiert genau einmal, im Gerüst. Die bestehenden Charts haben das Beispiel beim Kopieren entweder ersetzt oder entfernt.

Die Wirkung ist deshalb rein zukünftig — aber unangenehm konkret: ein neuer Chart, der das Beispiel übernimmt, rendert einen configMapKeyRef auf ein Objekt, das nicht existiert. Der Pod bleibt in CreateContainerConfigError hängen, und die Meldung nennt den fehlenden ConfigMap-Namen, nicht den Tippfehler in der Werte-Datei. Man sucht dann im Template, wo alles richtig ist.

Das verstößt zudem gegen den Grundsatz „Values that must not lie" aus der README: eine Vorgabe, die so nicht funktioniert, ist eine falsche Aussage über den Chart.

Gefunden bei

Umsetzung von #157/#43 für template-chart (PR #177). Der Entwicklungs-Agent hat den Punkt bewusst nicht mitrepariert, weil eine geänderte Werte-Vorgabe die gerenderte Ausgabe verändert und außerhalb des damaligen Auftrags lag — richtig so, deshalb dieses Issue. In der neuen NOTES.txt des Gerüsts ist der Punkt als Falle benannt.

Zu entscheiden bei der Umsetzung

Ein Zeichen in values.yaml, oder das Beispiel gleich so umbauen, dass es auf den configMapKey der mitgelieferten ConfigMap zeigt und damit funktioniert statt nur syntaktisch zu stimmen. Die zweite Variante wäre die ehrlichere Vorlage.
Versionssprung nach den Konventionen: geänderte Werte-Vorgabe, aber am Gerüst, das nicht veröffentlicht wird. Zu klären, ob hier überhaupt gebumpt wird.
Prüfen, ob dasselbe Muster im Gerüst noch an weiteren Stellen steht (Secret-Beispiel daneben sieht korrekt aus, aber das gehört mitgeprüft statt angenommen).

> Migriert aus [`jk-cluster/helm-charts#184`](https://github.com/jk-cluster/helm-charts/issues/184) — urspruenglich angelegt von **jk-cluster-bot** am 2026-08-28. > > Verweise der Form `#123` im folgenden Text beziehen sich auf die **GitHub-Nummerierung**, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar. --- Das `env`-Beispiel in `template-chart/values.yaml` verweist auf eine ConfigMap, die der Chart unter diesem Namen nicht anlegt. Wer den Chart kopiert und das Beispiel stehen lässt, bekommt einen Pod, der nicht startet. ## Belegt `template-chart/values.yaml`, Zeilen 109–113: ```yaml - name: ENV_FROM_CONFIGMAP valueFrom: configMapKeyRef: name: "{{ .Release.Name }}-{{ .Chart.Name }}-config-map" key: "configMapKey" ``` `template-chart/templates/xxx.configmap.yaml`, Zeile 4: ```yaml name: "{{ .Release.Name }}-{{ .Chart.Name }}-configmap" ``` `config-map` gegen `configmap`. Das Beispiel zeigt ins Leere. ## Auswirkung **Kein ausgelieferter Chart ist betroffen.** Gegengeprüft über alle `*/values.yaml` auf `origin/main`: der Treffer existiert genau einmal, im Gerüst. Die bestehenden Charts haben das Beispiel beim Kopieren entweder ersetzt oder entfernt. Die Wirkung ist deshalb rein zukünftig — aber unangenehm konkret: ein neuer Chart, der das Beispiel übernimmt, rendert einen `configMapKeyRef` auf ein Objekt, das nicht existiert. Der Pod bleibt in `CreateContainerConfigError` hängen, und die Meldung nennt den fehlenden ConfigMap-Namen, nicht den Tippfehler in der Werte-Datei. Man sucht dann im Template, wo alles richtig ist. Das verstößt zudem gegen den Grundsatz „Values that must not lie" aus der README: eine Vorgabe, die so nicht funktioniert, ist eine falsche Aussage über den Chart. ## Gefunden bei Umsetzung von #157/#43 für `template-chart` (PR #177). Der Entwicklungs-Agent hat den Punkt bewusst **nicht** mitrepariert, weil eine geänderte Werte-Vorgabe die gerenderte Ausgabe verändert und außerhalb des damaligen Auftrags lag — richtig so, deshalb dieses Issue. In der neuen `NOTES.txt` des Gerüsts ist der Punkt als Falle benannt. ## Zu entscheiden bei der Umsetzung - Ein Zeichen in `values.yaml`, oder das Beispiel gleich so umbauen, dass es auf den `configMapKey` der mitgelieferten ConfigMap zeigt und damit **funktioniert** statt nur syntaktisch zu stimmen. Die zweite Variante wäre die ehrlichere Vorlage. - Versionssprung nach den Konventionen: geänderte Werte-Vorgabe, aber am Gerüst, das nicht veröffentlicht wird. Zu klären, ob hier überhaupt gebumpt wird. - Prüfen, ob dasselbe Muster im Gerüst noch an weiteren Stellen steht (Secret-Beispiel daneben sieht korrekt aus, aber das gehört mitgeprüft statt angenommen).

jlab-bot referenced this issue

2026-09-16 16:04:27 +02:00

Repository, Workflows und Issues nach Gitea (JLab-Git) umziehen #14

jlab-bot commented

2026-10-04 21:26:35 +02:00

Nachgeprüft am 2026-10-04: unverändert offen, und es ist ein Zeichen

Der Chart legt eine ConfigMap an — template-chart/templates/xxx.configmap.yaml:4:

name: "{{ .Release.Name }}-{{ .Chart.Name }}-configmap"

Das env-Beispiel verweist auf einen anderen Namen — template-chart/values.yaml:112:

name: "{{ .Release.Name }}-{{ .Chart.Name }}-config-map"

config-map gegen configmap, ein Bindestrich. Wer das Beispiel übernimmt, bekommt einen Pod in CreateContainerConfigError und eine Meldung, die auf eine fehlende ConfigMap zeigt, während die ConfigMap existiert — nur unter dem anderen Namen.

Behebung ist ein Zeichen in values.yaml. Weil template-chart/ die Referenzumsetzung ist, pflanzt sich der Fehler in jeden Chart fort, der von dort kopiert wird.

## Nachgeprüft am 2026-10-04: unverändert offen, und es ist ein Zeichen Der Chart legt eine ConfigMap an — `template-chart/templates/xxx.configmap.yaml:4`: ``` name: "{{ .Release.Name }}-{{ .Chart.Name }}-configmap" ``` Das `env`-Beispiel verweist auf einen anderen Namen — `template-chart/values.yaml:112`: ``` name: "{{ .Release.Name }}-{{ .Chart.Name }}-config-map" ``` `config-map` gegen `configmap`, ein Bindestrich. Wer das Beispiel übernimmt, bekommt einen Pod in `CreateContainerConfigError` und eine Meldung, die auf eine fehlende ConfigMap zeigt, während die ConfigMap existiert — nur unter dem anderen Namen. Behebung ist ein Zeichen in `values.yaml`. Weil `template-chart/` die Referenzumsetzung ist, pflanzt sich der Fehler in jeden Chart fort, der von dort kopiert wird.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#10