From 5e47191252550ee75201f0e6b4aa50c8b29e4d9c Mon Sep 17 00:00:00 2001 From: Justin Klein Date: Tue, 6 Oct 2026 11:04:16 +0000 Subject: [PATCH] docs(ci): three runs, and the load explanation does not hold --- ci/keycloak/test-values.yaml | 38 +++++++++++++++++++----------------- 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/ci/keycloak/test-values.yaml b/ci/keycloak/test-values.yaml index b8583b6..4f9a76a 100644 --- a/ci/keycloak/test-values.yaml +++ b/ci/keycloak/test-values.yaml @@ -30,24 +30,26 @@ # first over the database would fail the run. Measured in Gitea PR #87: # 71.8s from `helm install` to both Ready, 0 restarts - three runs, all # three 72s and 0 restarts. -# THE FOURTH RUN WAS NOT THAT, AND THE NUMBER IS RECORDED RATHER THAN -# SMOOTHED (Gitea PR #92, run 585): 101s, and ONE restart on one of the two -# pods. The same run was measurably slower everywhere - the UNCHANGED -# postgres fixture took 51.5s to roll out instead of 27.4s - so the runner -# was about half as fast, and this chart's first install is where that -# shows: two replicas serialize on the Liquibase migration lock, which is -# the whole reason settings.env budgets 900s. WHAT THE RESTART WAS HAS NOT -# BEEN ESTABLISHED, because the harness dumps container logs only when a -# run FAILS, and this one passed - which is the lasting finding here: the -# green path cannot explain a restart it reports. -# WHAT DID SETTLE THE QUESTION WAS A SECOND RUN OF THE IDENTICAL MANIFESTS -# (run 590): 82s, 0 restarts, postgres back to 23.4s. Same chart, same -# theme mount, fast runner - so the restart belongs to the environment and -# not to the pod spec. Keep both numbers: "0 restarts" is an observation -# about four runs on a runner of varying speed, not an invariant of the -# chart, and a first install that serializes two replicas on a schema -# migration lock is exactly the shape that gets slower-than-linearly worse -# on a loaded machine. +# THE NEXT THREE RUNS WERE NOT THAT, AND THE NUMBERS ARE RECORDED RATHER +# THAN SMOOTHED (Gitea PR #92, same manifests in all three - the two later +# commits change only comments): +# run 585: 101s, ONE restart on one of the two pods +# run 590: 82s, 0 restarts +# run 593: 191s, 0 restarts +# So the restart is NOT caused by the pod spec: the fastest and the slowest +# run both had none, and the run that had one sat between them. The first +# explanation that offered itself does not survive the third run either - +# run 585 was slower everywhere (the UNCHANGED postgres fixture took 51.5s +# instead of 27.4s), but run 593 was slower still and restarted nothing, so +# "a loaded runner trips the first install" is not what was measured. +# WHAT THE RESTART WAS HAS NOT BEEN ESTABLISHED, and that is the lasting +# finding: the harness dumps container logs only when a run FAILS +# (diagnose() hangs off the EXIT trap behind "RC -ne 0"), and all three runs +# passed - A GREEN RUN CANNOT EXPLAIN A RESTART IT REPORTS. Whoever next +# needs that answer has to make the final-state step print the restart +# reasons when any counter is above zero. +# Read "0 restarts" accordingly: an observation about six runs on a runner +# of varying speed, not an invariant of this chart. # 5. A MOUNTED LOGIN THEME SURVIVES ALL OF THAT (Gitea #88) - the full # argument sits at keycloak.extraVolumes further down, including what it # still does not prove.