feat(keycloak): extraVolumes/extraVolumeMounts for themes and providers (1.1.0+up26.8.0) #92

Merged

jklein merged 8 commits from feat/keycloak-extra-volumes into main 2026-10-06 14:01:34 +02:00

Conversation 5 Commits 8 Files Changed 6

+249 -3

jlab-bot commented 2026-10-06 12:32:45 +02:00

Member

Copy link

Copy source

keycloak bekommt keycloak.extraVolumes / keycloak.extraVolumeMounts — generisch, additiv, Vorgaben unverändert ([]). Damit kommt überhaupt erst eine Datei in diesen Pod: Login-Theme, SPI-Erweiterung, zusätzliche Wurzel-CA. Minor: 1.0.0+up26.8.0 → 1.1.0+up26.8.0.

Die eine Entscheidung, die nicht naheliegt

extraVolumeMounts wird am build-Init-Container und am Hauptcontainer gerendert, aus einer Liste.

Ein Theme wird zur Laufzeit gelesen — dafür reicht der Hauptcontainer. Eine SPI-Erweiterung nicht: dieser Chart fährt start --optimized, und kc.sh build läuft im build-Init-Container. Upstream wörtlich: "After that if you are using --optimized, you must run the build command in order to update the server's provider registry with the implementations from the JAR file." Ein Provider-JAR, das nur am Hauptcontainer hängt, ist zur Augmentierungszeit nicht da — es landet nie in der Registry, die Datei liegt zur Laufzeit herum und nichts meldet das. Kein Fehler, keine Warnung.

Nicht am seed-Init-Container (anderes Layout, /quarkus-build, kein Keycloak-Kommando). Die Begründung steht am Wert und an beiden Stellen im Template, weil genau diese scheinbar redundante Zweitstelle die nächste Aufräumrunde entfernen würde — und kein Test, der auf Ready prüft, das bemerken kann.

Nebenwirkung, am Wert benannt: ein Extra-Volume ist damit auch zur Bauzeit vorhanden. Für ein Theme folgenlos, bei einem Geheimnis sieht es ein Init-Container ebenfalls.

Die Falle

Nicht auf /opt/keycloak/themes mounten. Dort liegen base, keycloak, keycloak.v2 — ein Volume an diesem Pfad verdeckt alle drei, die Anmeldeseite ist kaputt und der Pod bleibt Ready, weil /health/* nichts über Themes weiß. Der Mount gehört auf /opt/keycloak/themes/<name>, einen Unterpfad, den das Abbild nicht hat. Gleicher Mechanismus wie das vorhandene DELIBERATELY NOT MOUNTED: /opt/keycloak/conf; Beispiel und Begründung stehen in values.yaml.

Truststore-Frage: Grenze dokumentiert, kein zweiter Wert

Eine CA in den Pod zu legen fügt sie keinem Truststore hinzu. Der Chart bekommt keinen Truststore-Wert; stattdessen steht die Grenze ausdrücklich am Wert, zusammen mit dem Weg: KC_TRUSTSTORE_PATHS ist eine Laufzeit-Option (26.8.0-Optionstabelle, kein Build-Icon), also über keycloak.env setzbar — die Build-Option-Sperre verweigert ihn nicht. Verifiziert per Render. Dieser PR löst das Mounten, nicht zwei Themen.

Der Install-Test geht den Pfad wirklich

ci/keycloak/fixtures.yaml bekommt ein minimales, echtes Login-Theme als ConfigMap (parent=keycloak.v2, kcLogoIdP-ci-provider), test-values.yaml hängt es auf /opt/keycloak/themes/ci-theme ein — über items[].path, weil ein ConfigMap-Key keinen Schrägstrich tragen darf und das login/-Verzeichnis genau diese Indirektion braucht.

Was ein grüner Lauf schließt:

1. Ein Mount auf einem Unterpfad eines im Abbild vorhandenen Verzeichnisses wird neben readOnlyRootFilesystem: true akzeptiert — die Laufzeit muss den Mountpunkt in einem Dateisystem anlegen, das gleich schreibgeschützt wird.
2. kc.sh build läuft weiter mit dem zusätzlichen Mount — die Hälfte, die wegen der Doppelstelle zählt.
3. start --optimized kommt mit einem Laufzeit-Theme hoch. Der Issue-Body nannte das „begründete Erwartung, nicht geprüft"; das ist die Prüfung.

Was er nicht schließt, und das ist hier leicht zu überzeichnen: dass die Anmeldeseite rendert und base/keycloak/keycloak.v2 noch gelistet sind. Die Health-Endpunkte antworten unabhängig vom Themes-Verzeichnis, und nichts in dieser Harness ruft / auf oder führt ein Kommando im Pod aus. Dass der Unterpfad nichts verdeckt, ist eine Eigenschaft des Mount-Pfads, keine Messung. Steht so in test-values.yaml und auf der Wiki-Seite.

Schema

Beide Schlüssel sind deklariert — ohne das lehnt additionalProperties: false auf der obersten Ebene sie ab. Die Elemente bleiben locker typisiert (["array", "null"]), weil eine Volume-Quelle jede Kubernetes-Form annehmen kann und ein strengeres Schema gültige Konfigurationen abweisen würde statt Fehler zu fangen; der API-Server validiert die Form ohnehin. Der Grund steht in der description, damit die nächste Runde es nicht „nachzieht".

Lokal geprüft

• ci/helm-dependencies.sh keycloak, helm lint --strict keycloak (Vorgaben und Fixture-Werte): 0 Findings
• helm template gegen Vorgaben: kein Extra-Volume, volumes: unverändert dreimal emptyDir
• helm template gegen Fixture-Werte: login-theme in volumes: und in beiden volumeMounts (Build-Init + Haupt), items[].path: login/theme.properties korrekt
• keycloak.extraVolumes=null / extraVolumeMounts=null: rendert, with überspringt
• Schema in beide Richtungen: Tippfehler keycloak.extraVolume → additional properties 'extraVolume' not allowed; String statt Liste → got string, want null or array; eine secret-Quelle plus KC_TRUSTSTORE_PATHS über keycloak.env → akzeptiert
• Build-Option-Sperre unverändert scharf: keycloak.env[0].name=KC_DB scheitert mit der benannten Meldung
• ci/run-quantity-render-test.sh keycloak: ok, beide Fälle
• helm package → keycloak-1.1.0+up26.8.0.tgz

Nicht geprüft (hier nicht möglich): kein k3d, kein Docker/Podman, kein Trivy — Install-Test und Trivy-Scan belegen sich nur über die CI dieses PRs.

Wiki

Die keycloak-Seite um die beiden Werte, einen Abschnitt „Getting a file into the pod" mit dem Theme-Beispiel, die Falle als eigenen Trap und den CI-Absatz erweitert; Lessons-Learned um The mount that would have arrived after the build it was for plus eine Zeile in „The recurring shape" — die Form kehrt bei jedem Chart mit vorgezogener Augmentierung wieder. Kein neuer Eintrag in Charts oder _Sidebar, der Chart existiert schon. Wiki-Commit eed0689, signiert, rebased gepusht, nicht force.

Warum Part of und nicht Fixes

Von den drei Abnahmekriterien des Issues ist nur das erste hier belegbar:

1. Render mit ConfigMap-Theme auf /opt/keycloak/themes/<name> — geprüft, und darüber hinaus im Install-Test eingehängt.
2. Offen: „Die mitgelieferten Themes sind danach noch vorhanden (Anmeldeseite lädt)" — braucht einen HTTP-Aufruf auf /; in CI antwortet kein Ingress-Controller und nichts führt ein Kommando im Pod aus.
3. Offen: „kcLogoIdP-<alias> wirkt" — braucht einen Browser und die Theme-Auswahl im Realm, die kein Chart setzen kann.

Beides ist Betriebsabnahme im echten Cluster, keine offene Chart-Arbeit. Das Issue bleibt deshalb nach dem Merge offen, bis 2 und 3 am laufenden Keycloak gesehen wurden.

Part of #88

`keycloak` bekommt `keycloak.extraVolumes` / `keycloak.extraVolumeMounts` — generisch, additiv, Vorgaben unverändert (`[]`). Damit kommt überhaupt erst eine Datei in diesen Pod: Login-Theme, SPI-Erweiterung, zusätzliche Wurzel-CA. **Minor**: `1.0.0+up26.8.0` → `1.1.0+up26.8.0`. ## Die eine Entscheidung, die nicht naheliegt **`extraVolumeMounts` wird am `build`-Init-Container *und* am Hauptcontainer gerendert**, aus *einer* Liste. Ein Theme wird zur Laufzeit gelesen — dafür reicht der Hauptcontainer. Eine SPI-Erweiterung nicht: dieser Chart fährt `start --optimized`, und `kc.sh build` läuft im `build`-Init-Container. Upstream wörtlich: *"After that if you are using `--optimized`, you must run the `build` command in order to update the server's provider registry with the implementations from the JAR file."* Ein Provider-JAR, das nur am Hauptcontainer hängt, ist zur Augmentierungszeit nicht da — es landet nie in der Registry, die Datei liegt zur Laufzeit herum und **nichts meldet das**. Kein Fehler, keine Warnung. Nicht am `seed`-Init-Container (anderes Layout, `/quarkus-build`, kein Keycloak-Kommando). Die Begründung steht **am Wert und an beiden Stellen im Template**, weil genau diese scheinbar redundante Zweitstelle die nächste Aufräumrunde entfernen würde — und kein Test, der auf `Ready` prüft, das bemerken kann. Nebenwirkung, am Wert benannt: ein Extra-Volume ist damit auch zur Bauzeit vorhanden. Für ein Theme folgenlos, bei einem Geheimnis sieht es ein Init-Container ebenfalls. ## Die Falle **Nicht auf `/opt/keycloak/themes` mounten.** Dort liegen `base`, `keycloak`, `keycloak.v2` — ein Volume an diesem Pfad verdeckt alle drei, die Anmeldeseite ist kaputt und der Pod bleibt `Ready`, weil `/health/*` nichts über Themes weiß. Der Mount gehört auf `/opt/keycloak/themes/<name>`, einen Unterpfad, den das Abbild nicht hat. Gleicher Mechanismus wie das vorhandene `DELIBERATELY NOT MOUNTED: /opt/keycloak/conf`; Beispiel und Begründung stehen in `values.yaml`. ## Truststore-Frage: Grenze dokumentiert, kein zweiter Wert Eine CA in den Pod zu legen fügt sie keinem Truststore hinzu. Der Chart bekommt **keinen** Truststore-Wert; stattdessen steht die Grenze ausdrücklich am Wert, zusammen mit dem Weg: `KC_TRUSTSTORE_PATHS` ist eine **Laufzeit**-Option (26.8.0-Optionstabelle, kein Build-Icon), also über `keycloak.env` setzbar — die Build-Option-Sperre verweigert ihn nicht. Verifiziert per Render. Dieser PR löst das Mounten, nicht zwei Themen. ## Der Install-Test geht den Pfad wirklich `ci/keycloak/fixtures.yaml` bekommt ein minimales, echtes Login-Theme als ConfigMap (`parent=keycloak.v2`, `kcLogoIdP-ci-provider`), `test-values.yaml` hängt es auf `/opt/keycloak/themes/ci-theme` ein — über `items[].path`, weil ein ConfigMap-Key keinen Schrägstrich tragen darf und das `login/`-Verzeichnis genau diese Indirektion braucht. Was ein grüner Lauf schließt: 1. Ein Mount auf einem Unterpfad eines im Abbild **vorhandenen** Verzeichnisses wird neben `readOnlyRootFilesystem: true` akzeptiert — die Laufzeit muss den Mountpunkt in einem Dateisystem anlegen, das gleich schreibgeschützt wird. 2. `kc.sh build` läuft weiter mit dem zusätzlichen Mount — die Hälfte, die wegen der Doppelstelle zählt. 3. `start --optimized` kommt mit einem Laufzeit-Theme hoch. Der Issue-Body nannte das „begründete Erwartung, nicht geprüft"; das ist die Prüfung. **Was er nicht schließt, und das ist hier leicht zu überzeichnen:** dass die **Anmeldeseite rendert** und `base`/`keycloak`/`keycloak.v2` noch gelistet sind. Die Health-Endpunkte antworten unabhängig vom Themes-Verzeichnis, und nichts in dieser Harness ruft `/` auf oder führt ein Kommando im Pod aus. Dass der Unterpfad nichts verdeckt, ist eine Eigenschaft des Mount-Pfads, keine Messung. Steht so in `test-values.yaml` und auf der Wiki-Seite. ## Schema Beide Schlüssel sind deklariert — ohne das lehnt `additionalProperties: false` auf der obersten Ebene sie ab. Die **Elemente** bleiben locker typisiert (`["array", "null"]`), weil eine Volume-Quelle jede Kubernetes-Form annehmen kann und ein strengeres Schema gültige Konfigurationen abweisen würde statt Fehler zu fangen; der API-Server validiert die Form ohnehin. Der Grund steht in der `description`, damit die nächste Runde es nicht „nachzieht". ## Lokal geprüft - `ci/helm-dependencies.sh keycloak`, `helm lint --strict keycloak` (Vorgaben **und** Fixture-Werte): 0 Findings - `helm template` gegen Vorgaben: **kein** Extra-Volume, `volumes:` unverändert dreimal `emptyDir` - `helm template` gegen Fixture-Werte: `login-theme` in `volumes:` und in **beiden** `volumeMounts` (Build-Init + Haupt), `items[].path: login/theme.properties` korrekt - `keycloak.extraVolumes=null` / `extraVolumeMounts=null`: rendert, `with` überspringt - Schema in beide Richtungen: Tippfehler `keycloak.extraVolume` → `additional properties 'extraVolume' not allowed`; String statt Liste → `got string, want null or array`; eine `secret`-Quelle plus `KC_TRUSTSTORE_PATHS` über `keycloak.env` → akzeptiert - Build-Option-Sperre unverändert scharf: `keycloak.env[0].name=KC_DB` scheitert mit der benannten Meldung - `ci/run-quantity-render-test.sh keycloak`: ok, beide Fälle - `helm package` → `keycloak-1.1.0+up26.8.0.tgz` **Nicht geprüft** (hier nicht möglich): kein k3d, kein Docker/Podman, kein Trivy — Install-Test und Trivy-Scan belegen sich nur über die CI dieses PRs. ## Wiki Die `keycloak`-Seite um die beiden Werte, einen Abschnitt „Getting a file into the pod" mit dem Theme-Beispiel, die Falle als eigenen Trap und den CI-Absatz erweitert; `Lessons-Learned` um *The mount that would have arrived after the build it was for* plus eine Zeile in „The recurring shape" — die Form kehrt bei jedem Chart mit vorgezogener Augmentierung wieder. Kein neuer Eintrag in `Charts` oder `_Sidebar`, der Chart existiert schon. Wiki-Commit `eed0689`, signiert, rebased gepusht, nicht force. ## Warum `Part of` und nicht `Fixes` Von den drei Abnahmekriterien des Issues ist nur das erste hier belegbar: 1. Render mit ConfigMap-Theme auf `/opt/keycloak/themes/<name>` — geprüft, und darüber hinaus im Install-Test eingehängt. 2. Offen: „Die mitgelieferten Themes sind danach noch vorhanden (Anmeldeseite lädt)" — braucht einen HTTP-Aufruf auf `/`; in CI antwortet kein Ingress-Controller und nichts führt ein Kommando im Pod aus. 3. Offen: „`kcLogoIdP-<alias>` wirkt" — braucht einen Browser und die Theme-Auswahl im Realm, die kein Chart setzen kann. Beides ist Betriebsabnahme im echten Cluster, keine offene Chart-Arbeit. Das Issue bleibt deshalb nach dem Merge offen, bis 2 und 3 am laufenden Keycloak gesehen wurden. Part of #88

jlab-bot added 1 commit 2026-10-06 12:32:49 +02:00

feat(keycloak): extraVolumes/extraVolumeMounts for custom themes and providers (1.1.0+up26.8.0) d8b392bf64

jklein added 1 commit 2026-10-06 12:46:58 +02:00

docs(ci): record the keycloak install-test run that was slower and restarted once 1cf59f5448

jklein added 1 commit 2026-10-06 12:54:49 +02:00

docs(ci): the second run settles it - the keycloak restart was the runner, not the pod spec 34c600f7a8

jlab-bot commented 2026-10-06 12:56:00 +02:00

Author

Member

Copy link

Copy source

Nachtrag: ein Restart im ersten Install-Test, nachgegangen und geklärt

Der erste Lauf (585) war grün, zeigte aber im Endzustand etwas, das die drei keycloak-Läufe aus PR #87 nicht zeigten:

ci-keycloak-deployment-6b7fb8c94c-gh579   1/1  Running  1 (34s ago)  101s
ci-keycloak-deployment-6b7fb8c94c-p9tvm   1/1  Running  0            101s
OK: chart 'keycloak' installed and all workloads are Ready.

101 s und ein Restart, gegen dreimal 72 s und 0 Restarts in PR #87 (Läufe 487/489/490, alle drei identisch). Da dieser PR Mounts am build-Init-Container hinzufügt, war das nicht als Flake abzutun.

Erster Hinweis aus demselben Log: der Lauf war überall langsamer. Die unveränderte Postgres-Fixture brauchte 51,5 s statt 27,4 s — der Runner war etwa halb so schnell. Und genau hier schlägt das durch: der Erstinstall serialisiert zwei Replicas am Liquibase-Migrations-Lock, weshalb settings.env 900 s budgetiert.

Entschieden hat es ein zweiter Lauf mit identischen Manifesten (590, der Commit darauf ändert nur Kommentare):

ci-keycloak-deployment-6b7fb8c94c-2lncs   1/1  Running  0  82s
ci-keycloak-deployment-6b7fb8c94c-ht9rl   1/1  Running  0  82s

82 s, 0 Restarts, Postgres wieder bei 23,4 s — gleicher Chart, gleicher Theme-Mount, schneller Runner. Der Restart gehört damit zur Umgebung und nicht zur Pod-Spezifikation.

Was dabei nicht geklärt werden konnte, und das ist der bleibende Befund: was der Restart war. Die Harness schüttet Container-Logs nur im Fehlerfall aus (diagnose() hängt am EXIT-Trap mit RC -ne 0), und beide Läufe waren grün — ein grüner Lauf kann einen Restart, den er selbst meldet, nicht erklären. Das ist ein Kandidat für eine Harness-Verbesserung (im Endzustand die Restart-Gründe mitschreiben, sobald ein Zähler > 0 ist), gehört aber nicht in dieses Issue: es wäre eine Änderung an ci/run-install-test.sh mit eigener CI-CD-Wiki-Pflicht.

Beide Messungen stehen jetzt in ci/keycloak/test-values.yaml und auf der Wiki-Seite, mit der Lesart „Beobachtung über vier Läufe auf einem Runner schwankender Geschwindigkeit, keine Invariante des Charts" — die alte Formulierung „0 restarts" las sich als Zusage.

## Nachtrag: ein Restart im ersten Install-Test, nachgegangen und geklärt Der erste Lauf (585) war grün, zeigte aber im Endzustand etwas, das die drei keycloak-Läufe aus PR #87 nicht zeigten: ``` ci-keycloak-deployment-6b7fb8c94c-gh579 1/1 Running 1 (34s ago) 101s ci-keycloak-deployment-6b7fb8c94c-p9tvm 1/1 Running 0 101s OK: chart 'keycloak' installed and all workloads are Ready. ``` **101 s und ein Restart**, gegen **dreimal 72 s und 0 Restarts** in PR #87 (Läufe 487/489/490, alle drei identisch). Da dieser PR Mounts am `build`-Init-Container hinzufügt, war das nicht als Flake abzutun. **Erster Hinweis aus demselben Log:** der Lauf war überall langsamer. Die **unveränderte** Postgres-Fixture brauchte **51,5 s** statt **27,4 s** — der Runner war etwa halb so schnell. Und genau hier schlägt das durch: der Erstinstall serialisiert zwei Replicas am Liquibase-Migrations-Lock, weshalb `settings.env` 900 s budgetiert. **Entschieden hat es ein zweiter Lauf mit identischen Manifesten** (590, der Commit darauf ändert nur Kommentare): ``` ci-keycloak-deployment-6b7fb8c94c-2lncs 1/1 Running 0 82s ci-keycloak-deployment-6b7fb8c94c-ht9rl 1/1 Running 0 82s ``` **82 s, 0 Restarts**, Postgres wieder bei 23,4 s — gleicher Chart, gleicher Theme-Mount, schneller Runner. Der Restart gehört damit zur Umgebung und nicht zur Pod-Spezifikation. **Was dabei nicht geklärt werden konnte, und das ist der bleibende Befund:** *was* der Restart war. Die Harness schüttet Container-Logs nur im Fehlerfall aus (`diagnose()` hängt am EXIT-Trap mit `RC -ne 0`), und beide Läufe waren grün — **ein grüner Lauf kann einen Restart, den er selbst meldet, nicht erklären.** Das ist ein Kandidat für eine Harness-Verbesserung (im Endzustand die Restart-Gründe mitschreiben, sobald ein Zähler > 0 ist), gehört aber nicht in dieses Issue: es wäre eine Änderung an `ci/run-install-test.sh` mit eigener `CI-CD`-Wiki-Pflicht. Beide Messungen stehen jetzt in `ci/keycloak/test-values.yaml` und auf der Wiki-Seite, mit der Lesart „Beobachtung über vier Läufe auf einem Runner schwankender Geschwindigkeit, keine Invariante des Charts" — die alte Formulierung „0 restarts" las sich als Zusage.

jklein added 1 commit 2026-10-06 13:04:18 +02:00

docs(ci): three runs, and the load explanation does not hold 5e47191252

jlab-bot commented 2026-10-06 13:05:01 +02:00

Author

Member

Copy link

Copy source

Korrektur zum Nachtrag: die Lastvermutung hält nicht

Der dritte Lauf (593, Commit ändert nur Kommentare — identische Manifeste) ist dazugekommen:

ci-keycloak-deployment-6b7fb8c94c-29vg5   1/1  Running  0  3m11s
ci-keycloak-deployment-6b7fb8c94c-cnb64   1/1  Running  0  3m11s

191 s, 0 Restarts. Damit sieht die Reihe so aus — alle drei mit demselben Chart und demselben Theme-Mount:

Lauf	Zeit bis beide Ready	Restarts
585	101 s	1
590	82 s	0
593	191 s	0

Der schnellste und der langsamste Lauf haben keinen Restart, der mittlere hat einen. Das schließt die Pod-Spezifikation weiterhin aus — aber es widerlegt auch meine erste Erklärung aus dem Kommentar davor: „ein belasteter Runner reißt den Erstinstall" ist nicht das, was gemessen wurde. Ich habe sie in ci/keycloak/test-values.yaml und auf der Wiki-Seite entsprechend zurückgenommen; dort stehen jetzt alle drei Zahlen und ausdrücklich, dass die Ursache offen ist.

Der bleibende Befund ist unverändert und unabhängig von diesem PR: diagnose() hängt am EXIT-Trap hinter RC -ne 0, also schüttet die Harness Container-Logs nur im Fehlerfall aus — ein grüner Lauf kann einen Restart, den er selbst meldet, nicht erklären. Wer die Antwort braucht, muss den Endzustands-Schritt die Restart-Gründe mitschreiben lassen, sobald ein Zähler über null liegt. Das ist eine Änderung an ci/run-install-test.sh mit eigener CI-CD-Wiki-Pflicht und gehört nicht in dieses Issue.

## Korrektur zum Nachtrag: die Lastvermutung hält nicht Der dritte Lauf (593, Commit ändert nur Kommentare — identische Manifeste) ist dazugekommen: ``` ci-keycloak-deployment-6b7fb8c94c-29vg5 1/1 Running 0 3m11s ci-keycloak-deployment-6b7fb8c94c-cnb64 1/1 Running 0 3m11s ``` **191 s, 0 Restarts.** Damit sieht die Reihe so aus — alle drei mit demselben Chart und demselben Theme-Mount: | Lauf | Zeit bis beide `Ready` | Restarts | | --- | --- | --- | | 585 | 101 s | **1** | | 590 | 82 s | 0 | | 593 | 191 s | 0 | Der **schnellste und der langsamste** Lauf haben keinen Restart, der mittlere hat einen. Das schließt die Pod-Spezifikation weiterhin aus — aber es widerlegt auch meine erste Erklärung aus dem Kommentar davor: „ein belasteter Runner reißt den Erstinstall" ist **nicht** das, was gemessen wurde. Ich habe sie in `ci/keycloak/test-values.yaml` und auf der Wiki-Seite entsprechend zurückgenommen; dort stehen jetzt alle drei Zahlen und ausdrücklich, dass die Ursache **offen** ist. Der bleibende Befund ist unverändert und unabhängig von diesem PR: `diagnose()` hängt am EXIT-Trap hinter `RC -ne 0`, also schüttet die Harness Container-Logs nur im Fehlerfall aus — **ein grüner Lauf kann einen Restart, den er selbst meldet, nicht erklären.** Wer die Antwort braucht, muss den Endzustands-Schritt die Restart-Gründe mitschreiben lassen, sobald ein Zähler über null liegt. Das ist eine Änderung an `ci/run-install-test.sh` mit eigener `CI-CD`-Wiki-Pflicht und gehört nicht in dieses Issue.

jklein added 1 commit 2026-10-06 13:13:48 +02:00

docs(ci): the whole restart series, intermittent on an unchanged spec d7067abfab

jlab-bot commented 2026-10-06 13:14:24 +02:00

Author

Member

Copy link

Copy source

Die ganze Reihe, und was sie nicht sagt

Lauf 595 (wieder nur Kommentar-Commit, identische Pod-Spezifikation) hat erneut einen Restart:

Lauf	Zeit bis beide Ready	Restarts
585	101 s	1
590	82 s	0
593	191 s	0
595	101 s	1

Drei Beobachtungen, die mehr wert sind als ein Mittelwert:

• Der Restart ist intermittent bei unveränderter Spezifikation (2 von 4).
• Er ist immer genau einer, auf einem Pod, etwa 35 s bevor dieser Pod Ready meldet.
• Er folgt nicht der Runner-Geschwindigkeit: der schnellste (82 s) und der langsamste (191 s) Lauf haben keinen, die beiden mit Restart lagen beide bei 101 s. Damit ist meine erste Erklärung endgültig vom Tisch.

Was ich nicht geklärt habe, und ausdrücklich nicht behaupte: was der Restart ist. diagnose() hängt am EXIT-Trap hinter RC -ne 0, also schüttet die Harness Container-Logs nur im Fehlerfall aus — alle vier Läufe waren grün. Dass ein Erstinstall zwei Replicas am Liquibase-Migrations-Lock serialisiert, ist ein plausibler Ort dafür; gemessen hat das hier nichts, und so steht es auch in ci/keycloak/test-values.yaml und im Wiki.

Was ich auch nicht ausschließen kann: dass der Theme-Mount die Startzeit so verschiebt, dass eine Schwelle gelegentlich gerissen wird. Gegen diese Lesart spricht, dass der Basiswert aus PR #87 nur drei Läufe umfasst (alle 72 s, 0 Restarts) — also ein Basiswert ohne beobachtete Streuung, nicht ein Basiswert mit nachgewiesener Stabilität. Ein belastbares A/B bräuchte mehrere Läufe mit und ohne Mount auf demselben Runner; das sind mehrere Commits Rauschen auf diesem Branch, und ich habe es deshalb nicht gemacht, sondern lege die Entscheidung hier offen. Wenn du das belegt haben willst, bevor das hier nach main geht, sag es — dann messe ich es als A/B und berichte die Zahlen.

Die eigentliche Lücke ist ohnehin die Harness und nicht dieser Chart: ein grüner Lauf kann einen Restart, den er selbst meldet, nicht erklären. Das ist ein eigenes Issue wert (Endzustands-Schritt schreibt die Restart-Gründe mit, sobald ein Zähler über null liegt — Änderung an ci/run-install-test.sh, mit CI-CD-Wiki-Pflicht).

Ab hier zähle ich nicht weiter mit: jeder weitere Commit fügt einen Lauf hinzu, und ein Kommentar, der dem Stand nachläuft, ist beim nächsten Push falsch.

## Die ganze Reihe, und was sie nicht sagt Lauf 595 (wieder nur Kommentar-Commit, identische Pod-Spezifikation) hat erneut einen Restart: | Lauf | Zeit bis beide `Ready` | Restarts | | --- | --- | --- | | 585 | 101 s | **1** | | 590 | 82 s | 0 | | 593 | 191 s | 0 | | 595 | 101 s | **1** | Drei Beobachtungen, die mehr wert sind als ein Mittelwert: - Der Restart ist **intermittent bei unveränderter Spezifikation** (2 von 4). - Er ist **immer genau einer, auf einem Pod**, etwa 35 s bevor dieser Pod `Ready` meldet. - Er folgt **nicht** der Runner-Geschwindigkeit: der schnellste (82 s) und der langsamste (191 s) Lauf haben keinen, die beiden mit Restart lagen beide bei 101 s. Damit ist meine erste Erklärung endgültig vom Tisch. **Was ich nicht geklärt habe, und ausdrücklich nicht behaupte:** *was* der Restart ist. `diagnose()` hängt am EXIT-Trap hinter `RC -ne 0`, also schüttet die Harness Container-Logs nur im Fehlerfall aus — alle vier Läufe waren grün. Dass ein Erstinstall zwei Replicas am Liquibase-Migrations-Lock serialisiert, ist ein *plausibler* Ort dafür; gemessen hat das hier nichts, und so steht es auch in `ci/keycloak/test-values.yaml` und im Wiki. **Was ich auch nicht ausschließen kann:** dass der Theme-Mount die Startzeit so verschiebt, dass eine Schwelle gelegentlich gerissen wird. Gegen diese Lesart spricht, dass der Basiswert aus PR #87 nur **drei** Läufe umfasst (alle 72 s, 0 Restarts) — also ein Basiswert ohne beobachtete Streuung, nicht ein Basiswert mit nachgewiesener Stabilität. Ein belastbares A/B bräuchte mehrere Läufe mit und ohne Mount auf demselben Runner; das sind mehrere Commits Rauschen auf diesem Branch, und ich habe es deshalb **nicht** gemacht, sondern lege die Entscheidung hier offen. Wenn du das belegt haben willst, bevor das hier nach `main` geht, sag es — dann messe ich es als A/B und berichte die Zahlen. Die eigentliche Lücke ist ohnehin die Harness und nicht dieser Chart: **ein grüner Lauf kann einen Restart, den er selbst meldet, nicht erklären.** Das ist ein eigenes Issue wert (Endzustands-Schritt schreibt die Restart-Gründe mit, sobald ein Zähler über null liegt — Änderung an `ci/run-install-test.sh`, mit `CI-CD`-Wiki-Pflicht). Ab hier zähle ich nicht weiter mit: jeder weitere Commit fügt einen Lauf hinzu, und ein Kommentar, der dem Stand nachläuft, ist beim nächsten Push falsch.

jklein added 1 commit 2026-10-06 13:22:27 +02:00

test(ci): A/B control run - keycloak install-test without the theme mount (temporary) 71cc545277

jklein added 1 commit 2026-10-06 13:29:46 +02:00

test(ci): control run 598 recorded (81s, 0 restarts) 8cd0c14e3f

jklein added 1 commit 2026-10-06 13:43:47 +02:00

test(ci): restore the theme mount - the A/B shows the restart is pre-existing 6e196c26a5

jlab-bot commented 2026-10-06 13:45:09 +02:00

Author

Member

Copy link

Copy source

A/B gelaufen: der Restart ist nicht von diesem PR

Nach fünf Läufen stand es 3 von 5 mit Mount gegen 0 von 3 (PR #87) ohne — das liest sich wie eine Regression, und aus einem grünen Log ist es nicht zu klären. Also habe ich den Kontrollfall auf demselben Runner gemessen: das Wertepaar in ci/keycloak/test-values.yaml auskommentiert, womit der Pod-Template-Hash auf 5844db56b6 zurückgeht — genau der, den PR #87 gemessen hat. Der Vergleich ist damit byte-identisch und nicht „ungefähr gleich".

	Lauf	Zeit	Restarts
mit Theme-Mount	585	101 s	1
	590	82 s	0
	593	191 s	0
	595	101 s	1
	597	111 s	1
ohne (5844db56b6)	598	81 s	0
	599	171 s	1

Der Restart tritt ohne den Mount genauso auf. Er ist vorbestehendes, intermittierendes Verhalten des Erstinstalls dieses Charts — immer genau einer, auf einem Pod — und er folgt nicht der Runner-Geschwindigkeit: der schnellste (81 s) und der langsamste (191 s) Lauf der ganzen Reihe haben keinen. Die drei saubere Läufe aus PR #87 waren ein schneller Nachmittag, keine Eigenschaft des Charts.

Der Mount ist mit 6e196c2 wieder drin, wörtlich wie vorher (git diff d7067ab -- ci/keycloak/test-values.yaml zeigt im Wertepaar keine Zeile).

Was offen bleibt, und es ist nicht dieser Chart: was der Restart ist. diagnose() hängt am EXIT-Trap hinter RC -ne 0, also schüttet die Harness Container-Logs nur im Fehlerfall aus — alle sieben Läufe waren grün. Ein grüner Lauf kann einen Restart, den er selbst meldet, nicht erklären. Die Antwort kostet eine Zeile im Endzustands-Schritt (Restart-Gründe mitschreiben, sobald ein Zähler über null liegt), ist aber eine Änderung an ci/run-install-test.sh mit eigener CI-CD-Wiki-Pflicht und gehört in ein eigenes Issue, nicht in #88.

Beides steht jetzt dauerhaft in ci/keycloak/test-values.yaml und auf der Wiki-Seite; die Methode („ein Zähler, der sich zusammen mit einer Änderung bewegt, ist kein Beweis, bevor der Kontrollfall auf derselben Maschine gelaufen ist") als eigener Lessons-Learned-Eintrag.

## A/B gelaufen: der Restart ist nicht von diesem PR Nach fünf Läufen stand es 3 von 5 mit Mount gegen 0 von 3 (PR #87) ohne — das liest sich wie eine Regression, und aus einem grünen Log ist es nicht zu klären. Also habe ich den **Kontrollfall auf demselben Runner** gemessen: das Wertepaar in `ci/keycloak/test-values.yaml` auskommentiert, womit der Pod-Template-Hash auf **`5844db56b6`** zurückgeht — genau der, den PR #87 gemessen hat. Der Vergleich ist damit byte-identisch und nicht „ungefähr gleich". | | Lauf | Zeit | Restarts | | --- | --- | --- | --- | | **mit** Theme-Mount | 585 | 101 s | **1** | | | 590 | 82 s | 0 | | | 593 | 191 s | 0 | | | 595 | 101 s | **1** | | | 597 | 111 s | **1** | | **ohne** (`5844db56b6`) | 598 | 81 s | 0 | | | 599 | 171 s | **1** | **Der Restart tritt ohne den Mount genauso auf.** Er ist vorbestehendes, intermittierendes Verhalten des Erstinstalls dieses Charts — immer genau einer, auf einem Pod — und er folgt nicht der Runner-Geschwindigkeit: der schnellste (81 s) und der langsamste (191 s) Lauf der ganzen Reihe haben keinen. Die drei saubere Läufe aus PR #87 waren ein schneller Nachmittag, keine Eigenschaft des Charts. Der Mount ist mit `6e196c2` **wieder drin**, wörtlich wie vorher (`git diff d7067ab -- ci/keycloak/test-values.yaml` zeigt im Wertepaar keine Zeile). **Was offen bleibt, und es ist nicht dieser Chart:** *was* der Restart ist. `diagnose()` hängt am EXIT-Trap hinter `RC -ne 0`, also schüttet die Harness Container-Logs nur im Fehlerfall aus — alle sieben Läufe waren grün. **Ein grüner Lauf kann einen Restart, den er selbst meldet, nicht erklären.** Die Antwort kostet eine Zeile im Endzustands-Schritt (Restart-Gründe mitschreiben, sobald ein Zähler über null liegt), ist aber eine Änderung an `ci/run-install-test.sh` mit eigener `CI-CD`-Wiki-Pflicht und gehört in ein eigenes Issue, nicht in #88. Beides steht jetzt dauerhaft in `ci/keycloak/test-values.yaml` und auf der Wiki-Seite; die Methode („ein Zähler, der sich zusammen mit einer Änderung bewegt, ist kein Beweis, bevor der Kontrollfall auf derselben Maschine gelaufen ist") als eigener `Lessons-Learned`-Eintrag.

jklein approved these changes 2026-10-06 14:01:30 +02:00

jklein merged commit 6e196c26a5 into main 2026-10-06 14:01:34 +02:00

jklein deleted branch feat/keycloak-extra-volumes 2026-10-06 14:01:34 +02:00

jlab-bot referenced this pull request 2026-10-06 14:03:14 +02:00

ci/run-install-test.sh: ein gruener Lauf meldet Restarts, die er nicht erklaeren kann #93

jlab-bot referenced this pull request 2026-10-06 14:03:14 +02:00

Konvention: zusaetzliche Volumes heissen <chart>.extraVolumes / .extraVolumeMounts #94

Sign in to join this conversation.

Reviewers

No Reviewers

jklein

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

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#92