tegwick
9643e07ef5
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 276069@bnt-lap001 Assistant-Session: 2e192b3d-b3e8-4403-94d4-d55a2c8b476c
89 lines
6.2 KiB
Markdown
89 lines
6.2 KiB
Markdown
---
|
|
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: active
|
|
flavor: implementation
|
|
owner: claude
|
|
topic_slug: infotech
|
|
created: "2026-10-21"
|
|
updated: "2026-10-21"
|
|
related:
|
|
- CUST-WP-0071
|
|
- RESOURCE-WP-0008
|
|
state_hub_workstream_id: "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
|
|
|
|
```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)"
|
|
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
|
|
|
|
```task
|
|
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.
|