keycloak: the install-test timing is an observation, not an invariant

jklein committed 2026-10-06 10:55:10 +00:00
1 parent eed0689a43
commit 5e5b726dce
1 file changed
+3 -1
+3 -1
@@ -399,7 +399,9 @@ This chart renders **no** NetworkPolicy. If one is ever added, it has to allow 7
`ci/keycloak/` carries `test-values.yaml`, `fixtures.yaml` (throwaway PostgreSQL, the two Secrets the operator would materialize, and a minimal login-theme ConfigMap) and `settings.env` (`INSTALL_TIMEOUT=900`).
**The install-test runs with two replicas**, and the rollout is complete only when **both** pods are Ready — so a second replica that cannot start, deadlocks on the schema migration lock or fights the first over the database fails the run. Measured in Gitea PR #87: **71.8 seconds** from `helm install` to both pods Ready, 0 restarts.
**The install-test runs with two replicas**, and the rollout is complete only when **both** pods are Ready — so a second replica that cannot start, deadlocks on the schema migration lock or fights the first over the database fails the run. Measured in Gitea PR #87: **71.8 seconds** from `helm install` to both pods Ready, 0 restarts — three runs, all three the same.
**Read that as an observation and not as an invariant.** A fourth run (PR #92) took **101s and restarted one of the two pods once**, and the same run was slower everywhere — the *unchanged* postgres fixture needed 51.5s instead of 27.4s. A fifth run of the identical manifests was back at 82s with 0 restarts. So the restart belongs to the runner rather than to the pod spec, and the shape is worth remembering: a first install that serializes two replicas on the Liquibase migration lock degrades more than linearly on a loaded machine. **What the restart actually was could not be established, because the harness dumps container logs only when a run fails** — a green run cannot explain a restart it reports.
**What that does *not* prove is that `jdbc-ping` found the peer**, and reading it that way is the mistake this paragraph exists to prevent. Readiness reports *this* node's health, so a node that never found its peer is Ready, healthy and alone — and two such nodes are two islands that each believe they are the cluster. The Infinispan view has to be read out of the log, which is what step 2 of the first-install checklist is for. So the test rules out the louder half and leaves the quiet half to a human.