--- id: RPF-WP-0063 type: workplan title: "Wave-2 resource right-sizing from the 2026-10-21 allocation review" domain: financials repo: railiance-platform status: finished flavor: implementation owner: claude created: "2026-10-21" updated: "2026-10-21" related: - CUST-WP-0071 - RESOURCE-WP-0008 state_hub_workstream_id: "1fa22509-dc6e-5e5b-a0d4-70bb02898683" --- # RPF-WP-0063 — Wave-2 resource right-sizing from the 2026-10-21 allocation review Receiving workplan in `railiance-platform` for the wave-2 request changes below. The external-secrets workloads currently run with no requests at all (BestEffort). 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 request changes ```task id: RPF-WP-0063-T01 status: done priority: medium state_hub_task_id: "cea0abec-1e32-506b-aeb6-69b00037d2c8" ``` 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 | |---|---:|---:|---:|---:|---:|---:|---:|---:|---| | `external-secrets/external-secrets` | 1 | 0m → **10m** | 0m (1 container(s) without CPU limit) | 4.1/5.5 | 0Mi → **64Mi** | 0Mi | 51.2/53.3 | None | increase + memory up | | `external-secrets/external-secrets-cert-controller` | 1 | 0m → **10m** | 0m (1 container(s) without CPU limit) | 1.0/1.5 | 0Mi → **64Mi** | 0Mi | 42.2/51.4 | None | increase + memory up | | `external-secrets/external-secrets-webhook` | 1 | 0m → **10m** | 0m (1 container(s) without CPU limit) | 0.5/0.6 | 0Mi → **80Mi** | 0Mi | 63.2/111.9 | None | increase + memory up | | `openbao/railiance-platform` | 1 | 25m → **10m** | 200m | 0.2/0.5 | 32Mi → **32Mi** | 128Mi | 4.8/4.8 | 0.0 | decrease | | `playwright/rapp-playwright` | 1 | 100m → **65m** | 1000m | 41.5/62.7 | 256Mi → **336Mi** | 1024Mi | 285.1/437.2 | 0.238 | decrease + review CPU limit (throttled) + memory up | Source and container detail: - `external-secrets/external-secrets`: external-secrets controller Deployment (helm chart, Application draft `argocd/railiance01/drafts/external-secrets.application.yaml`); add `resources.requests` in the chart values — no requests are set today. - `external-secrets/external-secrets-cert-controller`: same chart, `certController.resources.requests`. - `external-secrets/external-secrets-webhook`: same chart, `webhook.resources.requests` (memory peak 112Mi). - `openbao/railiance-platform`: Deployment `railiance-platform` in namespace `openbao`; source not located by a quick search — identify it before changing. - `playwright/rapp-playwright`: Deployment `playwright`, container `service`, `rapp-playwright/manifests/workload.yaml` (deployed by rapp-playwright). 23.8% of CFS periods throttled at the 1000m limit: review the CPU limit too (RPF-WP-0056 covers admission, not sizing). 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. Prepared 2026-10-22 (wave-2 worker W3; no apply, cluster read-only). Each render was diffed against live with `kubectl diff` (Secret objects skipped): - `external-secrets` x3 — live source is Helm release `external-secrets` (rev 8, chart 0.16.1, not Argo; the Argo Application is still a draft). New `helm/external-secrets-resources.values.yaml` (force-added; `helm/*.yaml` is gitignored); the draft Application values mirror it. Render = chart 0.16.1 + `installCRDs: true` + `serviceAccount` (draft values minus the Argo CRD annotation, which live does not carry) + this file: diff = only the three Deployments' `resources.requests.{cpu,memory}`. Apply: `helm upgrade external-secrets external-secrets --repo https://charts.external-secrets.io --version 0.16.1 -n external-secrets --reuse-values -f helm/external-secrets-resources.values.yaml`. Restarts controller, cert-controller and webhook (brief ExternalSecret admission/refresh pause; no ingress impact). - `openbao/railiance-platform` = Deployment `openbao-ui-gateway` (label part-of railiance-platform), container `nginx`, `helm/openbao-ui-overlay-k8s.yaml`: CPU request 25m -> 10m. Rendered through `scripts/openbao-ui-overlay-apply.sh` with apply turned into diff: only `resources.requests.cpu`; ConfigMaps clean. Apply: `make openbao-overlay-apply` (it always does a rollout restart of the private UI gateway; OpenBao itself is untouched). - `databases/forgejo-db` (CNPG, `helm/forgejo-db-cluster.yaml`): requests 200m/512Mi -> 105m/288Mi, limits 1/1Gi unchanged. `shared_buffers` is not set (PostgreSQL default 128MB), well below the 288Mi request and the unchanged 1Gi limit, so memory is lowered as proposed. Diff of the full `forgejo-db-deploy` set: only `Cluster/forgejo-db` `spec.resources.requests`. Apply: `make forgejo-db-deploy`. CNPG restarts the single instance: Forgejo database outage for the restart; do it in the one-at-a-time DB window with a health check after. - `playwright/rapp-playwright`: live source is `rapp-playwright/manifests/workload.yaml` (commit `1557742` there). Request 100m/256Mi -> 65m/336Mi; CPU limit 1 -> 2 (throttle rule: new limit = max(2x current, 1000m); 2000m is 32x the 7d peak 62.7m). Server-side diff with field manager `rapp-playwright` (the live owner): only the three resource keys (NetworkPolicy: generation bump only). **Drift:** the repo's `make deploy` used the default field manager and would conflict on these fields; the Makefile now passes `--field-manager=rapp-playwright`. Apply (local kubectl): `make -C rapp-playwright render IMAGE_REFERENCE=` then `kubectl apply --server-side --field-manager=rapp-playwright -f rapp-playwright/.rendered/workload.yaml`. Strategy Recreate: the playwright pod is down for the restart (internal service only). 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. ## Applied — 2026-10-22 (RPF-WP-0063-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. ESO Helm revision 9; openbao UI gateway; forgejo-db restarted at 22:37Z with 105m/288Mi and is healthy (the forge stayed reachable); playwright (rapp-playwright) has a 2-core CPU limit, applied with field manager rapp-playwright. Evidence: the-custodian docs/evidence/2026-10-22-wave2-apply.md.