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

New Issue

2026-10-06T14:03:14+02:00

jlab-bot commented

2026-10-06 14:03:14 +02:00

Ein grüner Install-Test-Lauf meldet Restarts, die er nicht erklären kann. Die Zahl steht im Endzustand, die Ursache nirgends — und beides in derselben Ausgabe.

Woran es hängt

diagnose() in ci/run-install-test.sh hängt am EXIT-Trap hinter RC -ne 0. Container-Logs, Ereignisse und Container-Zustände werden also nur im Fehlerfall ausgeschüttet. Ein Lauf, der grün endet, nennt im Endzustands-Schritt die Restart-Zähler — und schweigt über die Gründe.

Das ist genau der Fall, der einen Beobachter zu einer falschen Erklärung einlädt, weil ihm nichts zum Prüfen vorliegt.

Gemessen in PR #92

Bei der Umsetzung von #88 zeigte ein grüner Lauf 1 Restart auf einem von zwei keycloak-Pods, wo die drei Läufe aus PR #87 dreimal 0 gezeigt hatten. Das liest sich wie eine Regression der dort hinzugefügten Volume-Werte.

Aufgelöst wurde es durch einen Kontrollfall auf demselben Runner: das Wertepaar auskommentiert, Pod-Template-Hash zurück auf 5844db56b6 — byte-identisch mit der in PR #87 gemessenen Spezifikation.

	Läufe	Dauer	Restarts
mit Mount	585 / 590 / 593 / 595 / 597	101 / 82 / 191 / 111 / 101 s	1 / 0 / 0 / 1 / 1
ohne Mount (`5844db56b6`)	598 / 599	81 / 171 s	0 / 1

Der Restart tritt ohne den Mount genauso auf — vorbestehend, intermittierend, immer genau einer auf einem Pod, und nicht an der Runner-Geschwindigkeit hängend: der schnellste Lauf (81 s) und der langsamste (191 s) hatten beide keinen.

Die Untersuchung hat damit beantwortet, was es nicht ist. Was es ist, konnte sie nicht beantworten, und zwar aus einem Grund, der behebbar ist: alle sieben Läufe waren grün, also gab es keine Diagnoseausgabe.

Vorschlag

Im Endzustands-Schritt von ci/run-install-test.sh: ist ein restartCount > 0, dann zusätzlich ausgeben

lastState.terminated.reason und exitCode des betroffenen Containers (kubectl get pod -o jsonpath),
das Protokoll des vorherigen Containers (kubectl logs --previous),
die Pod-Ereignisse.

Die Eigenschaft, die dabei nicht verloren gehen darf

Ein Lauf darf davon nicht rot werden. Das ist Diagnose, kein Torwächter. Würde ein Restart-Zähler den Lauf scheitern lassen, begännen ab sofort Builds an einem vorbestehenden, intermittierenden Restart zu scheitern, der nichts mit der jeweiligen Änderung zu tun hat — und die Lehre dieses Repositories ist, dass ein rotes Signal an der falschen Stelle schlimmer ist als ein stilles.

Die Ausgabe gehört in denselben Schritt wie die Zähler, damit „wie viele" und „warum" nebeneinander stehen und nicht in zwei Abschnitten.

Umfang

ci/run-install-test.sh — der Endzustands-Schritt.
Wiki-Seite CI-CD: Pipeline-Verhalten ändert sich, das ist nach der Tabelle in CLAUDE.md eine Pflicht. Dazu gehört der Satz, warum es Diagnose und kein Torwächter ist.
Beide Aufrufer der Harness sind davon betroffen (validate-charts.yml und install-test-all-charts.yml), aber nur über die gemeinsame Datei — es ist keine Änderung an den Workflow-Hüllen.

Nicht in diesem Umfang

Die Ursache des keycloak-Restarts. Dieses Issue macht sie sichtbar, es behebt sie nicht. Ob danach ein eigenes Issue nötig ist, entscheidet die erste Ausgabe.

Dringlichkeit

Niedrig, aber der Nutzen ist breit: es betrifft jeden künftigen Chart, dessen Pods im Install-Test neu starten, und es hat in PR #92 bereits einmal einen halben Tag Untersuchung gekostet, die mit zwei Zeilen Ausgabe nicht nötig gewesen wäre. Vier Kommentare an PR #92 dokumentieren den Weg, einschließlich der zurückgenommenen ersten Erklärung.

Ein grüner Install-Test-Lauf meldet Restarts, die er nicht erklären kann. Die Zahl steht im Endzustand, die Ursache nirgends — und beides in derselben Ausgabe. ## Woran es hängt `diagnose()` in `ci/run-install-test.sh` hängt am EXIT-Trap hinter `RC -ne 0`. Container-Logs, Ereignisse und Container-Zustände werden also **nur im Fehlerfall** ausgeschüttet. Ein Lauf, der grün endet, nennt im Endzustands-Schritt die Restart-Zähler — und schweigt über die Gründe. Das ist genau der Fall, der einen Beobachter zu einer falschen Erklärung einlädt, weil ihm nichts zum Prüfen vorliegt. ## Gemessen in PR #92 Bei der Umsetzung von #88 zeigte ein grüner Lauf **1 Restart** auf einem von zwei keycloak-Pods, wo die drei Läufe aus PR #87 dreimal 0 gezeigt hatten. Das liest sich wie eine Regression der dort hinzugefügten Volume-Werte. Aufgelöst wurde es durch einen Kontrollfall **auf demselben Runner**: das Wertepaar auskommentiert, Pod-Template-Hash zurück auf `5844db56b6` — byte-identisch mit der in PR #87 gemessenen Spezifikation. | | Läufe | Dauer | Restarts | | --- | --- | --- | --- | | mit Mount | 585 / 590 / 593 / 595 / 597 | 101 / 82 / 191 / 111 / 101 s | **1** / 0 / 0 / **1** / **1** | | ohne Mount (`5844db56b6`) | 598 / 599 | 81 / 171 s | 0 / **1** | **Der Restart tritt ohne den Mount genauso auf** — vorbestehend, intermittierend, immer genau einer auf einem Pod, und nicht an der Runner-Geschwindigkeit hängend: der schnellste Lauf (81 s) und der langsamste (191 s) hatten beide keinen. Die Untersuchung hat damit beantwortet, **was es nicht ist**. Was es ist, konnte sie nicht beantworten, und zwar aus einem Grund, der behebbar ist: alle sieben Läufe waren grün, also gab es keine Diagnoseausgabe. ## Vorschlag Im **Endzustands-Schritt** von `ci/run-install-test.sh`: ist ein `restartCount > 0`, dann zusätzlich ausgeben - `lastState.terminated.reason` und `exitCode` des betroffenen Containers (`kubectl get pod -o jsonpath`), - das Protokoll des **vorherigen** Containers (`kubectl logs --previous`), - die Pod-Ereignisse. ## Die Eigenschaft, die dabei nicht verloren gehen darf **Ein Lauf darf davon nicht rot werden.** Das ist Diagnose, kein Torwächter. Würde ein Restart-Zähler den Lauf scheitern lassen, begännen ab sofort Builds an einem vorbestehenden, intermittierenden Restart zu scheitern, der nichts mit der jeweiligen Änderung zu tun hat — und die Lehre dieses Repositories ist, dass ein rotes Signal an der falschen Stelle schlimmer ist als ein stilles. Die Ausgabe gehört in denselben Schritt wie die Zähler, damit „wie viele" und „warum" nebeneinander stehen und nicht in zwei Abschnitten. ## Umfang - `ci/run-install-test.sh` — der Endzustands-Schritt. - Wiki-Seite **`CI-CD`**: Pipeline-Verhalten ändert sich, das ist nach der Tabelle in CLAUDE.md eine Pflicht. Dazu gehört der Satz, warum es Diagnose und kein Torwächter ist. - Beide Aufrufer der Harness sind davon betroffen (`validate-charts.yml` und `install-test-all-charts.yml`), aber nur über die gemeinsame Datei — es ist **keine** Änderung an den Workflow-Hüllen. ## Nicht in diesem Umfang **Die Ursache des keycloak-Restarts.** Dieses Issue macht sie sichtbar, es behebt sie nicht. Ob danach ein eigenes Issue nötig ist, entscheidet die erste Ausgabe. ## Dringlichkeit Niedrig, aber der Nutzen ist breit: es betrifft jeden künftigen Chart, dessen Pods im Install-Test neu starten, und es hat in PR #92 bereits einmal einen halben Tag Untersuchung gekostet, die mit zwei Zeilen Ausgabe nicht nötig gewesen wäre. Vier Kommentare an PR #92 dokumentieren den Weg, einschließlich der zurückgenommenen ersten Erklärung.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#93