jlab-cluster/helm-charts
3
0 Fork 0
Code Issues 15 Pull Requests 3 Actions Packages Wiki Activity

satisfactory: bleibt server.storage bewusst ohne Null-Absicherung? #39

New Issue
Open
opened 2026-09-22 22:06:38 +02:00 by jlab-bot · 3 comments
jlab-bot commented 2026-09-22 22:06:38 +02:00
Member
Copy link
Copy source

satisfactory/values.schema.json hält für server.storage eine bewusste Ausnahme fest:

an erased value yields an invalid PVC rather than a silently degraded workload

Ein gelöschter Wert soll also kein Fallback auf 20Gi bekommen, sondern ein PVC ohne Größenangabe ergeben, das beim Anwenden laut scheitert. Diese Ausnahme steht — die Frage ist, ob sie nach dem Befund unten noch die richtige ist.

Woher die Frage kommt

Bei der Umsetzung von #16 (PR #37) wurden dev und server null-sicher gemacht. Der Umsetzungs-Agent hat storage dabei mit abgesichert und die Schema-Notiz ersetzt; das wurde zurückgenommen, damit #37 ein reiner Patch ohne Verhaltensänderung bleibt. Die Abwägung gehört hierher.

Das Argument dafür, die Ausnahme aufzugeben

Nach #37 fällt --set server=null für jeden Schlüssel des Blocks auf die dokumentierten Vorgaben zurück — außer für storage. Der Render läuft dann durch und erzeugt ein größenloses PVC. Das ist derselbe Stolperstein, den #16 beschreibt, nur eine Ebene höher: Wer sieht, dass server=null funktioniert, nimmt an, dass es vollständig funktioniert.

Die Inkonsistenz ist damit genau die, die #16 bei game bemängelt hat.

Das Argument dafür, sie zu behalten

Die Größe eines Volumes ist datenrelevant, und die Ausnahme macht den Unterschied nur an einer Stelle: bei einer neuen Installation. Dort bedeutet ein Fallback „du bekommst stillschweigend 20Gi", die Ausnahme dagegen „sag es ausdrücklich".

Bei einem bestehenden Release scheitert beides laut: Ein PVC lässt sich nicht verkleinern, ein Fallback auf 20Gi gegen ein vorhandenes 200Gi-Volume wird vom API-Server abgelehnt — genau wie das größenlose PVC. Der Unterschied ist also schmaler, als er zunächst aussieht.

Zu klären

  1. Ist „laut beim Anwenden" hier wirklich besser als „dokumentierte Vorgabe stillschweigend"? Die Repo-Linie sagt sonst, ein lautes Scheitern schlägt ein leises — hier steht sie gegen die Regel aus Richtlinie 12, dass ein leerer Block „Chart-Vorgaben gelten" bedeutet.
  2. Falls die Ausnahme fällt: Es ist eine Verhaltensänderung für eine Eingabe, die heute scheitert — also mindestens Minor, und die Schema-Notiz muss mit derselben Sorgfalt ersetzt werden, mit der sie geschrieben wurde.
  3. Falls sie bleibt: In values.yaml und auf der Wiki-Seite sichtbar machen, dass storage als einziger Schlüssel des Blocks nicht abgesichert ist, damit die Lücke nicht als Versehen gelesen wird.

Belegt

Gemessen im Rahmen von PR #37 (helm 3.22.0): Mit storage außerhalb der Helfer-Defaults rendert --set server=null ein PVC ohne resources.requests.storage; der Render selbst läuft durch. Mit storage in den Defaults rendert derselbe Aufruf 20Gi. Beides reproduzierbar über helm template.

`satisfactory/values.schema.json` hält für `server.storage` eine bewusste Ausnahme fest: > an erased value yields an invalid PVC rather than a silently degraded workload Ein gelöschter Wert soll also **kein** Fallback auf `20Gi` bekommen, sondern ein PVC ohne Größenangabe ergeben, das beim Anwenden laut scheitert. Diese Ausnahme steht — die Frage ist, ob sie nach dem Befund unten noch die richtige ist. ## Woher die Frage kommt Bei der Umsetzung von #16 (PR #37) wurden `dev` und `server` null-sicher gemacht. Der Umsetzungs-Agent hat `storage` dabei mit abgesichert und die Schema-Notiz ersetzt; das wurde **zurückgenommen**, damit #37 ein reiner Patch ohne Verhaltensänderung bleibt. Die Abwägung gehört hierher. ## Das Argument dafür, die Ausnahme aufzugeben Nach #37 fällt `--set server=null` für jeden Schlüssel des Blocks auf die dokumentierten Vorgaben zurück — außer für `storage`. Der Render läuft dann durch und erzeugt ein **größenloses PVC**. Das ist derselbe Stolperstein, den #16 beschreibt, nur eine Ebene höher: Wer sieht, dass `server=null` funktioniert, nimmt an, dass es vollständig funktioniert. Die Inkonsistenz ist damit genau die, die #16 bei `game` bemängelt hat. ## Das Argument dafür, sie zu behalten Die Größe eines Volumes ist datenrelevant, und die Ausnahme macht den Unterschied nur an einer Stelle: bei einer **neuen** Installation. Dort bedeutet ein Fallback „du bekommst stillschweigend 20Gi", die Ausnahme dagegen „sag es ausdrücklich". Bei einem **bestehenden** Release scheitert beides laut: Ein PVC lässt sich nicht verkleinern, ein Fallback auf 20Gi gegen ein vorhandenes 200Gi-Volume wird vom API-Server abgelehnt — genau wie das größenlose PVC. Der Unterschied ist also schmaler, als er zunächst aussieht. ## Zu klären 1. Ist „laut beim Anwenden" hier wirklich besser als „dokumentierte Vorgabe stillschweigend"? Die Repo-Linie sagt sonst, ein lautes Scheitern schlägt ein leises — hier steht sie gegen die Regel aus Richtlinie 12, dass ein leerer Block „Chart-Vorgaben gelten" bedeutet. 2. Falls die Ausnahme fällt: Es ist eine Verhaltensänderung für eine Eingabe, die heute scheitert — also mindestens **Minor**, und die Schema-Notiz muss mit derselben Sorgfalt ersetzt werden, mit der sie geschrieben wurde. 3. Falls sie bleibt: In `values.yaml` und auf der Wiki-Seite sichtbar machen, dass `storage` als einziger Schlüssel des Blocks **nicht** abgesichert ist, damit die Lücke nicht als Versehen gelesen wird. ## Belegt Gemessen im Rahmen von PR #37 (helm 3.22.0): Mit `storage` außerhalb der Helfer-Defaults rendert `--set server=null` ein PVC ohne `resources.requests.storage`; der Render selbst läuft durch. Mit `storage` in den Defaults rendert derselbe Aufruf `20Gi`. Beides reproduzierbar über `helm template`.
jlab-bot commented 2026-09-22 22:14:45 +02:00
Author
Member
Copy link
Copy source

Beleg nachgereicht, wie im Abschnitt "Belegt" angekündigt — dort steht der Befund bisher nur als Behauptung. Hier die vollständigen Ausgaben, damit niemand die Messung wiederholen muss. An der offenen Entscheidung ändert das nichts, es macht sie nur nachvollziehbar.

Umgebung

  • helm version --short → v3.22.0+g144ca65
  • Variante A (heutiger Stand, Ausnahme bleibt) = PR #37, Commit 839b882
  • Variante B (mit Fallback, verworfen) = frühere Fassung desselben Zweigs, Commit 57e54f9

Beide Varianten sind echte Commits, keine nachgebauten Dateien: ausgecheckt über archive in zwei getrennte Verzeichnisse und dort gerendert.

Der Befehl

helm template sf <chart> --set server=null --show-only templates/satisfactory.pvc.yaml

Beide Renderings laufen durch (Exit 0). Das ist der Kern der Sache: Der Unterschied ist keiner zwischen "geht" und "geht nicht", sondern einer zwischen zwei gültigen Renderings.

A — heutiger Stand, storage außerhalb der Helfer-Defaults

---
# Source: satisfactory/templates/satisfactory.pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sf-satisfactory-vc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 
  storageClassName: longhorn

(Die Zeile storage: endet mit einem Leerzeichen und keinem Wert — in YAML also null.)

B — storage in den Helfer-Defaults

---
# Source: satisfactory/templates/satisfactory.pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sf-satisfactory-vc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: longhorn

Der Unterschied über das gesamte Rendering

Nicht nur über das PVC, sondern über alle drei Objekte:

$ diff <(helm template sf A --set server=null) <(helm template sf B --set server=null)
12c12
<       storage: 
---
>       storage: 20Gi

Genau eine Zeile. Die Entscheidung hängt also an einem einzigen Feld und hat keine Nebenwirkungen anderswo im Chart.

Was ich nicht belegen kann

Dass der API-Server das größenlose PVC tatsächlich ablehnt, habe ich nicht nachgewiesen — im Coder-Workspace gibt es keine Berechtigung dafür (persistentvolumeclaims is forbidden), und ohne Cluster geht es nicht. Das "laut scheitern" aus der Schema-Notiz ist an dieser Stelle also unverifiziert übernommen, nicht gemessen.

Was ich dazu messen konnte, ist ein Datenpunkt, der vorher in keinem der beiden Argumente steht: Lokal beanstandet das größenlose PVC niemand.

$ kubectl create --dry-run=client -f pvc-sizeless.yaml
persistentvolumeclaim/sf-satisfactory-vc created (dry run)

Weder helm template noch helm lint --strict noch die clientseitige kubectl-Validierung sagen etwas. Wer das für die laute Variante hält, sollte wissen, wie spät der Laut kommt: erst beim echten Anwenden gegen einen Cluster, nicht beim Rendern und nicht in der Vorschau.

Ein Argument für die Beibehaltung, das hier noch fehlt

Bei server: null bleibt auch NOTES.txt ehrlich zum größenlosen PVC, statt eine Größe zu drucken, die im Manifest nicht steht:

Variante A:  notesprobe-satisfactory-vc (unset, storageClassName "longhorn")
Variante B:  notesprobe-satisfactory-vc (20Gi, storageClassName "longhorn")

Der Operator liest bei A also unset und nicht 20Gi — die Notes widersprechen dem Manifest nicht. Das ist ein Punkt für die Ausnahme.

Zwei Einschränkungen gehören dazu, wenn man es als Argument anführt:

  1. Es ist kein Entwurf, sondern Zufall der vorhandenen Vorlage. Die Zeile lautet seit jeher {{- $storage := $server.storage | default "unset" -}}. Dieses | default "unset" stammt nicht aus einer Überlegung zu dieser Ausnahme; es fällt hier nur günstig. Wenn die Ausnahme mit diesem Argument verteidigt wird, gehört die Absicht in einen Kommentar an dieser Zeile — sonst räumt sie die nächste Aufräumrunde weg, und das Argument verschwindet mit ihr.

  2. An einer zweiten Stelle liest es sich kaputt. Derselbe Wert wird im Fließtext noch einmal eingesetzt:

    so a large part of the unset on this claim is spoken for before the first
save is written

    Grammatisch unsinnig. Das ist kein Gegenargument zur Ausnahme, aber wenn sie bleibt, sollte dieser Satz den Fall ausdrücklich behandeln, statt den Platzhalter in einen Satz zu setzen, der eine Größe erwartet.

Zur Vollständigkeit: Punkt 3 der Liste "Zu klären" ist in PR #37 bereits umgesetzt — values.yaml, values.schema.json, der Helfer-Kommentar und die Wiki-Seite nennen storage als den einen Schlüssel des Blocks ohne Absicherung und verweisen auf dieses Issue. Das ist die Variante "Ausnahme bleibt, aber sichtbar"; sie nimmt der Entscheidung hier nichts vorweg, sondern verhindert nur, dass die Lücke in der Zwischenzeit als Versehen gelesen wird.

Beleg nachgereicht, wie im Abschnitt "Belegt" angekündigt — dort steht der Befund bisher nur als Behauptung. Hier die vollständigen Ausgaben, damit niemand die Messung wiederholen muss. **An der offenen Entscheidung ändert das nichts**, es macht sie nur nachvollziehbar. ## Umgebung - `helm version --short` → `v3.22.0+g144ca65` - Variante A (**heutiger Stand**, Ausnahme bleibt) = PR #37, Commit `839b882` - Variante B (**mit Fallback**, verworfen) = frühere Fassung desselben Zweigs, Commit `57e54f9` Beide Varianten sind echte Commits, keine nachgebauten Dateien: ausgecheckt über `archive` in zwei getrennte Verzeichnisse und dort gerendert. ## Der Befehl ``` helm template sf <chart> --set server=null --show-only templates/satisfactory.pvc.yaml ``` Beide Renderings **laufen durch** (Exit 0). Das ist der Kern der Sache: Der Unterschied ist keiner zwischen "geht" und "geht nicht", sondern einer zwischen zwei gültigen Renderings. ### A — heutiger Stand, `storage` außerhalb der Helfer-Defaults ```yaml --- # Source: satisfactory/templates/satisfactory.pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: sf-satisfactory-vc spec: accessModes: - ReadWriteOnce resources: requests: storage: storageClassName: longhorn ``` (Die Zeile `storage: ` endet mit einem Leerzeichen und keinem Wert — in YAML also `null`.) ### B — `storage` in den Helfer-Defaults ```yaml --- # Source: satisfactory/templates/satisfactory.pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: sf-satisfactory-vc spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: longhorn ``` ### Der Unterschied über das **gesamte** Rendering Nicht nur über das PVC, sondern über alle drei Objekte: ``` $ diff <(helm template sf A --set server=null) <(helm template sf B --set server=null) 12c12 < storage: --- > storage: 20Gi ``` Genau eine Zeile. Die Entscheidung hängt also an einem einzigen Feld und hat keine Nebenwirkungen anderswo im Chart. ## Was ich **nicht** belegen kann Dass der API-Server das größenlose PVC tatsächlich ablehnt, habe ich **nicht** nachgewiesen — im Coder-Workspace gibt es keine Berechtigung dafür (`persistentvolumeclaims is forbidden`), und ohne Cluster geht es nicht. Das "laut scheitern" aus der Schema-Notiz ist an dieser Stelle also unverifiziert übernommen, nicht gemessen. Was ich dazu **messen** konnte, ist ein Datenpunkt, der vorher in keinem der beiden Argumente steht: Lokal beanstandet das größenlose PVC **niemand**. ``` $ kubectl create --dry-run=client -f pvc-sizeless.yaml persistentvolumeclaim/sf-satisfactory-vc created (dry run) ``` Weder `helm template` noch `helm lint --strict` noch die clientseitige `kubectl`-Validierung sagen etwas. Wer das für die laute Variante hält, sollte wissen, wie spät der Laut kommt: erst beim echten Anwenden gegen einen Cluster, nicht beim Rendern und nicht in der Vorschau. ## Ein Argument für die Beibehaltung, das hier noch fehlt Bei `server: null` bleibt auch `NOTES.txt` ehrlich zum größenlosen PVC, statt eine Größe zu drucken, die im Manifest nicht steht: ``` Variante A: notesprobe-satisfactory-vc (unset, storageClassName "longhorn") Variante B: notesprobe-satisfactory-vc (20Gi, storageClassName "longhorn") ``` Der Operator liest bei A also `unset` und nicht `20Gi` — die Notes widersprechen dem Manifest nicht. Das ist ein Punkt für die Ausnahme. **Zwei Einschränkungen gehören dazu, wenn man es als Argument anführt:** 1. **Es ist kein Entwurf, sondern Zufall der vorhandenen Vorlage.** Die Zeile lautet seit jeher `{{- $storage := $server.storage | default "unset" -}}`. Dieses `| default "unset"` stammt nicht aus einer Überlegung zu dieser Ausnahme; es fällt hier nur günstig. Wenn die Ausnahme mit diesem Argument verteidigt wird, gehört die Absicht in einen Kommentar an dieser Zeile — sonst räumt sie die nächste Aufräumrunde weg, und das Argument verschwindet mit ihr. 2. **An einer zweiten Stelle liest es sich kaputt.** Derselbe Wert wird im Fließtext noch einmal eingesetzt: ``` so a large part of the unset on this claim is spoken for before the first save is written ``` Grammatisch unsinnig. Das ist kein Gegenargument zur Ausnahme, aber wenn sie bleibt, sollte dieser Satz den Fall ausdrücklich behandeln, statt den Platzhalter in einen Satz zu setzen, der eine Größe erwartet. --- Zur Vollständigkeit: Punkt 3 der Liste "Zu klären" ist in PR #37 bereits umgesetzt — `values.yaml`, `values.schema.json`, der Helfer-Kommentar und die Wiki-Seite nennen `storage` als den einen Schlüssel des Blocks ohne Absicherung und verweisen auf dieses Issue. Das ist die Variante "Ausnahme bleibt, aber sichtbar"; sie nimmt der Entscheidung hier nichts vorweg, sondern verhindert nur, dass die Lücke in der Zwischenzeit als Versehen gelesen wird.
jlab-bot commented 2026-09-22 22:15:40 +02:00
Author
Member
Copy link
Copy source

Entscheidung der Manager-Sitzung zum Beleg oben, damit nichts zwischen den beiden Vorgängen verloren geht.

Der kaputte NOTES-Satz wird nicht in #37 repariert. Er ist vorbestehend — über --set server.storage=null war er schon auf 7.0.0 erreichbar — und #37 hat nach der Rücknahme die nachgewiesene Eigenschaft, für jede Eingabe byte-identisch zu 7.0.0 zu rendern. Diese Eigenschaft ist mehr wert als die Reparatur eines Satzes, der seit Langem so dasteht: Sie ist der Grund, warum der PR ein Patch sein darf.

Er ist damit Teil dieses Issues, unabhängig vom Ausgang. Beide möglichen Entscheidungen lassen ihn übrig:

  • Bleibt die Ausnahme, muss der Satz den Fall „keine Größe gesetzt" behandeln, statt den Platzhalter in eine Formulierung zu setzen, die eine Größe erwartet.
  • Fällt die Ausnahme, verschwindet der Platzhalter — und mit ihm die Zeile | default "unset", an der das NOTES-Argument oben hängt.

Ein Punkt aus dem Beleg verdient beim Entscheiden besonderes Gewicht, weil er gegen die urspruengliche Begruendung der Ausnahme spricht: Das größenlose PVC wird lokal von niemandem beanstandet. helm template schweigt, helm lint --strict schweigt, und kubectl create --dry-run=client meldet sogar created. Das „laut scheitern", das die Schema-Notiz als Zweck angibt, kommt also erst beim echten Anwenden — nach Rendern, Linten, Vorschau und Review. Ob das noch als laut gilt, ist genau die Frage dieses Issues.

Dass die Ablehnung durch den API-Server selbst hier nicht nachgewiesen werden konnte (keine Berechtigung im Workspace), steht oben korrekt als uebernommen statt gemessen. Wer das Issue umsetzt, sollte es in einem Wegwerf-Cluster nachholen: Wenn ein größenloses PVC wider Erwarten nicht abgelehnt wird, fällt die Begruendung der Ausnahme vollstaendig in sich zusammen.

Entscheidung der Manager-Sitzung zum Beleg oben, damit nichts zwischen den beiden Vorgängen verloren geht. **Der kaputte NOTES-Satz wird nicht in #37 repariert.** Er ist vorbestehend — über `--set server.storage=null` war er schon auf 7.0.0 erreichbar — und #37 hat nach der Rücknahme die nachgewiesene Eigenschaft, für **jede** Eingabe byte-identisch zu 7.0.0 zu rendern. Diese Eigenschaft ist mehr wert als die Reparatur eines Satzes, der seit Langem so dasteht: Sie ist der Grund, warum der PR ein Patch sein darf. **Er ist damit Teil dieses Issues, unabhängig vom Ausgang.** Beide möglichen Entscheidungen lassen ihn übrig: - Bleibt die Ausnahme, muss der Satz den Fall „keine Größe gesetzt" behandeln, statt den Platzhalter in eine Formulierung zu setzen, die eine Größe erwartet. - Fällt die Ausnahme, verschwindet der Platzhalter — und mit ihm die Zeile `| default "unset"`, an der das NOTES-Argument oben hängt. **Ein Punkt aus dem Beleg verdient beim Entscheiden besonderes Gewicht**, weil er gegen die urspruengliche Begruendung der Ausnahme spricht: Das größenlose PVC wird lokal von niemandem beanstandet. `helm template` schweigt, `helm lint --strict` schweigt, und `kubectl create --dry-run=client` meldet sogar `created`. Das „laut scheitern", das die Schema-Notiz als Zweck angibt, kommt also erst beim echten Anwenden — nach Rendern, Linten, Vorschau und Review. Ob das noch als laut gilt, ist genau die Frage dieses Issues. Dass die Ablehnung durch den API-Server selbst hier nicht nachgewiesen werden konnte (keine Berechtigung im Workspace), steht oben korrekt als uebernommen statt gemessen. Wer das Issue umsetzt, sollte es in einem Wegwerf-Cluster nachholen: Wenn ein größenloses PVC wider Erwarten **nicht** abgelehnt wird, fällt die Begruendung der Ausnahme vollstaendig in sich zusammen.
jlab-bot commented 2026-09-22 22:16:37 +02:00
Author
Member
Copy link
Copy source

Nachtrag zur ausstehenden Messung — wie sie angelegt sein muss, damit sie etwas entscheidet.

Es genügt nicht, helm install in einem Wegwerf-Cluster laufen zu lassen und auf den Exit-Code zu sehen. Es gibt zwei mögliche Ausgänge, und sie führen zu gegensätzlichen Schlüssen:

  1. Die Validierung lehnt das fehlende resources.requests.storage ab. Dann scheitert das Anwenden tatsächlich laut, und die Begründung der Ausnahme steht — wenn auch spät, siehe oben.
  2. Der API-Server nimmt den Claim an und behandelt ihn als leere Ressourcenliste. Dann hängt das PVC Pending, ohne Fehlermeldung, und die Begründung der Ausnahme fällt vollständig in sich zusammen: Das Ergebnis ist dann nicht „laut statt leise", sondern ein Claim, der nie bindet und nichts dazu sagt. Das wäre exakt der Fehlermodus, gegen den dieses Repo seine Regeln geschrieben hat — nur diesmal von uns selbst eingebaut.

Zu belegen also mit kubectl get pvc -o yaml und den Events daneben, nicht am Rückgabewert von helm install. Ein Cluster mit Storage-Provisioner allein beantwortet die Frage nicht, weil der Provisioner erst nach der Validierung ins Spiel kommt.

Hintergrund: Beim Belegen oben hat sich gezeigt, dass lokal niemand etwas beanstandet — helm template, helm lint --strict und kubectl create --dry-run=client schweigen alle drei. Welcher der beiden Ausgänge eintritt, ist damit die einzige noch offene Tatsache in diesem Issue; alles andere ist Abwägung.

Nachtrag zur ausstehenden Messung — wie sie angelegt sein muss, damit sie etwas entscheidet. Es genügt nicht, `helm install` in einem Wegwerf-Cluster laufen zu lassen und auf den Exit-Code zu sehen. Es gibt **zwei** mögliche Ausgänge, und sie führen zu gegensätzlichen Schlüssen: 1. **Die Validierung lehnt das fehlende `resources.requests.storage` ab.** Dann scheitert das Anwenden tatsächlich laut, und die Begründung der Ausnahme steht — wenn auch spät, siehe oben. 2. **Der API-Server nimmt den Claim an** und behandelt ihn als leere Ressourcenliste. Dann hängt das PVC `Pending`, ohne Fehlermeldung, und die Begründung der Ausnahme fällt vollständig in sich zusammen: Das Ergebnis ist dann nicht „laut statt leise", sondern ein Claim, der nie bindet und nichts dazu sagt. Das wäre exakt der Fehlermodus, gegen den dieses Repo seine Regeln geschrieben hat — nur diesmal von uns selbst eingebaut. Zu belegen also mit `kubectl get pvc -o yaml` und den Events daneben, nicht am Rückgabewert von `helm install`. Ein Cluster mit Storage-Provisioner allein beantwortet die Frage nicht, weil der Provisioner erst nach der Validierung ins Spiel kommt. Hintergrund: Beim Belegen oben hat sich gezeigt, dass lokal niemand etwas beanstandet — `helm template`, `helm lint --strict` und `kubectl create --dry-run=client` schweigen alle drei. Welcher der beiden Ausgänge eintritt, ist damit die einzige noch offene Tatsache in diesem Issue; alles andere ist Abwägung.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
inhouse-chart
Inhouse-Chart aus der JLab-Git-Paketregistry
 renovate
Von Renovate angelegt
No labels
Milestone
No items
No Milestone
Assignees
Clear assignees
jklein (Justin Klein) jlab-bot (jlab-git-bot) jlab-renovate-bot (jlab-renovate-bot)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#39