From 40e999980f2a68c05362917fc582ddac83520975 Mon Sep 17 00:00:00 2001 From: Justin Klein Date: Tue, 6 Oct 2026 11:04:06 +0000 Subject: [PATCH] keycloak: the third install-test run disproves the load explanation --- keycloak.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/keycloak.md b/keycloak.md index 128c7d0..6cc37e1 100644 --- a/keycloak.md +++ b/keycloak.md @@ -401,7 +401,7 @@ This chart renders **no** NetworkPolicy. If one is ever added, it has to allow 7 **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. +**Read that as an observation and not as an invariant.** Three further runs of identical manifests in PR #92 measured **101s with one restart**, **82s with none**, and **191s with none**. The fastest and the slowest run restarted nothing and the middle one did, so it is not the pod spec — and it is not simply a loaded runner either, which was the first explanation and did not survive the 191s run. **What the restart 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. Whoever needs that answer has to make the final-state step print the restart reasons when a counter is above zero. **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.