core-hub/workplans/CORE-WP-0012-wave2-resource-right-sizing.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	related	state_hub_workstream_id
CORE-WP-0012	workplan	Wave-2 resource right-sizing from the 2026-10-21 allocation review	infotech	core-hub	active	implementation	claude	infotech	2026-10-21	2026-10-21	CUST-WP-0071 RESOURCE-WP-0008	89760de9-1586-5776-9b5d-29a06e7a11e8

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

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)"
state_hub_task_id: "bec05de1-24fc-555f-8622-0ca1b14f412f"

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.

Prepared 2026-10-21 (wave-2 worker W1a; not applied). Live owner is Helm release core-hub (rev 33) from rapp-core-hub (make deploy), not railiance-apps. Change: rapp-core-hub 8c2fa02, values/production.yaml request overrides, limits unchanged. Split of the 60m/288Mi aggregate by 7d per-pod p95: candidate core-hub-api-candidate (serves all routing groups) 50m/256Mi → 25m/128Mi; legacy core-hub-api 100m/512Mi → 15m/96Mi; core-hub-api-repository-publisher 50m/128Mi → 20m/64Mi. The full make render against live shows only resources.requests on the three Deployments (the baseline render before the change matched live exactly). Apply: cd rapp-core-hub && make deploy (helm upgrade --atomic --wait). All three pods roll (maxSurge 1, maxUnavailable 0). The pre-existing test_render_is_deterministic_and_digest_pinned failure (it expects the old forge URL) is unrelated to this change.

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 <ns> 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

id: CORE-WP-0012-T02
status: progress
priority: medium
state_hub_task_id: "f139ec33-80ec-5c07-a288-9767b13d804f"

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).

Uninstalled — 2026-10-21

helm uninstall ihp-railiance-probe -n coulomb succeeded under founder approval.

• The Deployment, Service and Ingress are gone; 50m CPU/128Mi was freed.
• Namespace coulomb was kept. Besides the defaults, it may still hold the probe's manually created env credential object, which agents may not inspect. The founder checks what is left and deletes the namespace if only that probe object remains.
• DNS for probe.coulomb.social still needs review.