railiance-platform/workplans/RPF-WP-0063-wave2-resource-right-sizing.md

id	type	title	domain	repo	status	flavor	owner	created	updated	related	state_hub_workstream_id
RPF-WP-0063	workplan	Wave-2 resource right-sizing from the 2026-10-21 allocation review	financials	railiance-platform	finished	implementation	claude	2026-10-21	2026-10-21	CUST-WP-0071 RESOURCE-WP-0008	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

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

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=<live digest> 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.