railiance-apps/workplans/RAPPS-WP-0018-wave2-resource-right-sizing.md
tegwick cd6cd38356
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Wave-2 right-sizing applied 2026-10-22 (CUST-WP-0071)
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
2026-10-22 00:52:51 +02:00

64 lines
6.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
id: RAPPS-WP-0018
type: workplan
title: "Wave-2 resource right-sizing from the 2026-10-21 allocation review"
domain: financials
repo: railiance-apps
status: finished
flavor: implementation
owner: claude
topic_slug: railiance
created: "2026-10-21"
updated: "2026-10-21"
related:
- CUST-WP-0071
- RESOURCE-WP-0008
state_hub_workstream_id: "c3f7c479-7477-5d5e-865d-a5d5b9e79ab8"
---
# RAPPS-WP-0018 — Wave-2 resource right-sizing from the 2026-10-21 allocation review
Receiving workplan in `railiance-apps` for the Vergabe memory request (replay-backed) and the latent Inter-Hub request.
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.
## Raise the Vergabe memory request and clear the latent inter-hub request
```task
id: RAPPS-WP-0018-T01
status: done
priority: medium
state_hub_task_id: "48a3c858-c65c-575c-8a97-4122245a1eca"
```
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 |
|---|---:|---:|---:|---:|---:|---:|---:|---:|---|
| `vergabe-demo-company/vergabe-teilnahme` | 1 | 60m → **60m** | 1000m | 0.5/20.3 | 256Mi → **512Mi** | 1024Mi | 171.5/171.6 | 0.0 | keep CPU (replay-backed) + memory up |
Source and container detail:
- `vergabe-demo-company/vergabe-teilnahme`: Deployment `vergabe-teilnahme` (container `vergabe-teilnahme`), `resources` in `helm/vergabe-demo-company-values.proposed.yaml` (60m/256Mi, limits 1000m/1Gi); the chart default in `charts/vergabe-teilnahme/values.yaml` (100m/256Mi) is not what is deployed. Keep the 60m CPU request and the 1000m/1Gi limits (replay-backed). Raise memory 256Mi → 512Mi: the target replay (`docs/evidence/2026-10-21-vergabe-target-replay/`, commit `1af6d82`, RAPPS-WP-0014-T04) showed a loaded working set of 320–480MiB.
**Prepared 2026-10-21 (wave-2 worker W1a; not applied).** Change: railiance-apps `b7fb7b2`.
- Vergabe: live Helm release `vergabe-teilnahme` in `vergabe-demo-company` (rev 3) matches `helm/vergabe-demo-company-values.proposed.yaml`. Memory request 256Mi → 512Mi for the app and the `migrate` init container, which share `resources`. CPU stays 60m and limits stay 1000m/1Gi. The full render against live adds **drift beyond resources**: the label `railiance.io/release-unit: vergabe` (from commit 64530e1, 2026-10-21) is missing on Service `vergabe-teilnahme` and both PVCs; the Deployment already has it. Because of this the apply comes to the founder. Apply: `helm upgrade vergabe-teilnahme charts/vergabe-teilnahme -n vergabe-demo-company -f helm/vergabe-demo-company-values.proposed.yaml --wait --timeout 5m`. Strategy is Recreate (short outage).
- Inter-Hub: the owner chose removal. Deleted `charts/inter-hub`, `helm/inter-hub-values.yaml`, the `inter-hub-*` Make targets, `tools/inter-hub-smoke.sh` and `.gitea/workflows/inter-hub-production-deploy.yaml`; the inter-hub part of `tools/k8s-server-dry-run.sh` is removed and the docs updated. Live: Deployment (0 replicas, 250m/512Mi), Service and 8 old ReplicaSets, all from Helm release `inter-hub` (rev 2); it has no Ingress. Apply: `helm uninstall inter-hub -n inter-hub`. Afterwards the founder checks for leftover credential objects, which agents do not inspect, before deleting the namespace. A stale rollback artifact `core-hub/k8s/railiance-production/rollback-inter-hub-ingress.yaml` (archived CORE-WP-0005) still points at the release.
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.
Inter-Hub: `charts/inter-hub/values.yaml` still defaults to `requests: {cpu: 250m, memory: 512Mi}` (limits 1000m/2Gi), and `helm/inter-hub-values.yaml` does not override it. The release runs at 0 replicas, so the 250m is latent: it is reserved again the moment anything scales it up or the deploy workflow (`.gitea/workflows/inter-hub-production-deploy.yaml`) runs. Inter-Hub is retired (CORE-WP-0007; production `hub.coulomb.social` is Core Hub only). Preferred: remove the inter-hub release and retire its chart and deploy workflow; otherwise lower the default request to the 5m floor so a scale-up cannot reserve 250m. Record which option the owner chose.
## Applied — 2026-10-22 (RAPPS-WP-0018-T01)
Applied under the founder's wave-2 authorization (the-custodian docs/decisions/2026-10-21-cust-wp-0071-delivery-interview.md), after a full-render diff against live that showed resources only, plus the founder-approved `railiance.io/release-unit` label. Vergabe memory 512Mi, Helm revision 4. The retired inter-hub release was uninstalled; namespace `inter-hub` is kept until the founder checks what is left in it. Evidence: the-custodian docs/evidence/2026-10-22-wave2-apply.md.