From 994aac3df3afce070de5717d362df8c4a0a3771d Mon Sep 17 00:00:00 2001 From: codex Date: Mon, 21 Sep 2026 18:37:51 +0200 Subject: [PATCH] Record State Hub's CPU request restored to 250m (helm rev 64). Co-Authored-By: Claude Opus 5 --- docs/kubernetes-change-gate-decision.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/kubernetes-change-gate-decision.md b/docs/kubernetes-change-gate-decision.md index 7f18664..1395ba8 100644 --- a/docs/kubernetes-change-gate-decision.md +++ b/docs/kubernetes-change-gate-decision.md @@ -163,3 +163,15 @@ The HPAs on the activator, gateway and webhook target 100% of the request. At ob - rail-knative must declare these requests, or the next upstream apply resets them. - Actual CPU use is about 70% on a single node. That is a capacity question for the railiance02 move, not something to settle here. - state-hub uses about 447m against a 100m request. It is *under*-requested. + +## State Hub request restored, 2026-09-21 + +State Hub's CPU request was **100m → 250m**, the chart's own default. The mode was `ADMINISTER @ realm:kubernetes/railiance01`, `activation=APPROVED` by the founder, done through state-hub's own promotion path. The 100m had been a declared override in `deploy/railiance/apps/helm/state-hub-values.yaml`, working around a node with less than 250m unallocated; that constraint is gone. + +**Steps:** +1. Changed the value in state-hub (commit `6b97d01`). +2. On railiance01, rendered the chart and diffed it against the live objects. The only substantive change was `cpu: 100m → 250m`, and the chart had not drifted from the live revision 63. +3. Ran the chart's headroom preflight: `ok: true`, 830m remaining. +4. Ran `helm upgrade --atomic` with the pinned image `main-0747b4d`, giving **revision 64**, 1/1 ready. + +Hub health afterwards: `ok`, db connected, schema `b5e6f7a8c9d0` as expected. There was no downtime (maxUnavailable=0).