From 9a4754a34393ef23d54e45b03f6b15984cdd879f Mon Sep 17 00:00:00 2001 From: tegwick Date: Wed, 21 Oct 2026 08:47:37 +0200 Subject: [PATCH] CORE-WP-0012: wave-2 resource right-sizing receiving workplan Receiving workplan for the 2026-10-21 node allocation review (RESOURCE-WP-0008-T03 / CUST-WP-0071-T03). Wave-2 apply is human-gated; no manifest changes. Co-Authored-By: Claude Opus 5.5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 8340@bnt-lap001 Assistant-Session: 2e192b3d-b3e8-4403-94d4-d55a2c8b476c --- ...ORE-WP-0012-wave2-resource-right-sizing.md | 78 +++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 workplans/CORE-WP-0012-wave2-resource-right-sizing.md diff --git a/workplans/CORE-WP-0012-wave2-resource-right-sizing.md b/workplans/CORE-WP-0012-wave2-resource-right-sizing.md new file mode 100644 index 0000000..a3a7ec6 --- /dev/null +++ b/workplans/CORE-WP-0012-wave2-resource-right-sizing.md @@ -0,0 +1,78 @@ +--- +id: CORE-WP-0012 +type: workplan +title: "Wave-2 resource right-sizing from the 2026-10-21 allocation review" +domain: infotech +repo: core-hub +status: ready +flavor: implementation +owner: claude +topic_slug: infotech +created: "2026-10-21" +updated: "2026-10-21" +related: + - CUST-WP-0071 + - RESOURCE-WP-0008 +--- + +# CORE-WP-0012 — Wave-2 resource right-sizing from the 2026-10-21 allocation review + +Receiving workplan in `core-hub` for the wave-2 request change and the cleanup of a release left behind by CORE-WP-0007. + +Origin: the 2026-10-21 node allocation review (`RESOURCE-WP-0008-T03`, feeding `CUST-WP-0071-T03`). Per the founder's 2026-10-21 delivery interview (`the-custodian/docs/decisions/2026-10-21-cust-wp-0071-delivery-interview.md`) the small adjustments form wave 2: one receiving task per owner repo, applied later in a batch. Applying wave 2 needs a separate founder approval, so every cluster-write task here is a human-gated `wait`. This file changes no manifest. + +## Apply the reviewed rapp-core-hub request changes + +```task +id: CORE-WP-0012-T01 +status: wait +priority: medium +needs_human: true +blocking_reason: "Wave-2 cluster write; founder approval for wave 2 not yet given (2026-10-21 interview)" +``` + +Values are pod-aggregate figures from the budget file (7-day window ending 2026-10-21T06:08Z). Limits stay unchanged unless stated. + +| Workload (ns/name) | Pods | CPU request | CPU limit | CPU p95/peak 7d (m) | Memory request | Memory limit | Mem p95/peak (Mi) | Throttle | Action | +|---|---:|---:|---:|---:|---:|---:|---:|---:|---| +| `core-hub/rapp-core-hub` | 3 | 200m → **60m** | 2500m | 39.2/63.5 | 896Mi → **288Mi** | 2560Mi | 247.0/292.0 | 0.002 | decrease + memory down | + +Source and container detail: + +- `core-hub/rapp-core-hub`: three pods; `resources` in `railiance-apps/charts/core-hub/values.yaml` (chart default 250m/512Mi, which does not match the live 200m/896Mi total — find the deployed values override first). Production `hub.coulomb.social`: verify startup time and a full rollout under the lower request before keeping it. + +Evidence: resource-control `docs/evidence/2026-10-21-node-allocation-review/2026-10-21-node-budget.md` (+ `.json`, commit `3d9b1bd`). Rule: CPU = max(floor, p95x1.5, peakx0.5) rounded up to 5m; memory request = 7d p95 working set x1.15 (only when the change is at least 64Mi). + +Steps: + +1. Map the pod-aggregate proposal onto the named container(s) in the source file; where a workload has several containers or pods, split by the per-pod figures in `2026-10-21-workload-usage.json` and keep the sum at the proposed value. +2. Prepare the source change as a reviewed commit (no push, no sync) and record the before values here. +3. Apply only inside the batched wave-2 rollout, after founder approval, through the owner's normal deploy path (ArgoCD sync or documented helm/kubectl apply). + +Verification: `kubectl -n get pod -o jsonpath='{..resources}'` shows the new requests; pods Ready with no new restarts or OOMKilled over 24h; for CPU decreases the throttle ratio and request latency stay at or below the 7d baseline; node request total drops by the expected delta. + +Rollback: revert the source commit and re-sync/re-apply; the before values in the table above are the rollback target. Keep before/after `kubectl get -o yaml` captures as the receipt. + +## Remove the leftover ihp-railiance-probe Helm release + +```task +id: CORE-WP-0012-T02 +status: wait +priority: medium +needs_human: true +blocking_reason: "Cluster write (helm uninstall in namespace coulomb) needs founder approval" +``` + +Follow-up to archived `CORE-WP-0007`: T01 retired the ihp-railiance-probe repository but left its Helm release running. The pod in namespace `coulomb` has been in ImagePullBackOff for about 21 days from the dead legacy registry `92.205.130.254:32166`, uses nothing and still reserves 50m CPU / 128Mi memory (limits 200m/256Mi). Two more stale pods were seen. + +Evidence: resource-control `docs/evidence/2026-10-21-node-allocation-review/2026-10-21-node-budget.md` (+ `.json`, commit `3d9b1bd`), row `coulomb/ihp-railiance-probe`. + +Steps (after approval): + +1. Record `helm -n coulomb list -a`, `helm -n coulomb get values ihp-railiance-probe` and `kubectl -n coulomb get all,pvc,secret,configmap -o name` as the before receipt. +2. `helm uninstall ihp-railiance-probe -n coulomb`. +3. Delete namespace `coulomb` only if `kubectl -n coulomb get all,pvc,secret,configmap` shows nothing besides defaults (`kube-root-ca.crt`, default ServiceAccount). + +Verification: no pods left in `coulomb`; node CPU requests drop by 50m; no ArgoCD Application or other repo references the release (search the fleet before step 2). + +Rollback: none needed for a dead release; if something unexpected depended on it, reinstall from the recorded values (the image is unreachable either way).