From 5e5b726dce1e47c05d72647b73c76734ee31c351 Mon Sep 17 00:00:00 2001 From: Justin Klein Date: Tue, 6 Oct 2026 10:55:10 +0000 Subject: [PATCH] keycloak: the install-test timing is an observation, not an invariant --- keycloak.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/keycloak.md b/keycloak.md index 092b828..128c7d0 100644 --- a/keycloak.md +++ b/keycloak.md @@ -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.