RAPPS-WP-0018: wave-2 resource right-sizing receiving workplan
Receiving workplan for the 2026-10-21 node allocation review (RESOURCE-WP-0008-T03 / CUST-WP-0071-T03). Wave-2 apply is human-gated; no manifest changes. WORK-RECORDS.md regenerated from staged sources. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 8340@bnt-lap001 Assistant-Session: 2e192b3d-b3e8-4403-94d4-d55a2c8b476c
This commit is contained in:
parent
1af6d828f5
commit
10465cb39c
2 changed files with 58 additions and 0 deletions
|
|
@ -15,6 +15,7 @@
|
|||
| workplan | RAPPS-WP-0015 | active | — | workplans/RAPPS-WP-0015-coulomb-personal-content-release.md |
|
||||
| workplan | RAPPS-WP-0016 | active | — | workplans/RAPPS-WP-0016-forgejo-netkingdom-login.md |
|
||||
| workplan | RAPPS-WP-0017 | finished | — | workplans/RAPPS-WP-0017-reuse-private-reader-release.md |
|
||||
| workplan | RAPPS-WP-0018 | ready | — | workplans/RAPPS-WP-0018-wave2-resource-right-sizing.md |
|
||||
| task | RAPPS-WP-0001-T01 | done | — | workplans/RAPPS-WP-0001-cnpg-backup-scheduledbackup-coverage.md |
|
||||
| task | RAPPS-WP-0001-T02 | done | — | workplans/RAPPS-WP-0001-cnpg-backup-scheduledbackup-coverage.md |
|
||||
| task | RAPPS-WP-0001-T03 | done | — | workplans/RAPPS-WP-0001-cnpg-backup-scheduledbackup-coverage.md |
|
||||
|
|
@ -51,3 +52,4 @@
|
|||
| task | RAPPS-WP-0017-T01 | done | — | workplans/RAPPS-WP-0017-reuse-private-reader-release.md |
|
||||
| task | RAPPS-WP-0017-T02 | done | — | workplans/RAPPS-WP-0017-reuse-private-reader-release.md |
|
||||
| task | RAPPS-WP-0017-T03 | done | — | workplans/RAPPS-WP-0017-reuse-private-reader-release.md |
|
||||
| task | RAPPS-WP-0018-T01 | wait | — | workplans/RAPPS-WP-0018-wave2-resource-right-sizing.md |
|
||||
|
|
|
|||
56
workplans/RAPPS-WP-0018-wave2-resource-right-sizing.md
Normal file
56
workplans/RAPPS-WP-0018-wave2-resource-right-sizing.md
Normal file
|
|
@ -0,0 +1,56 @@
|
|||
---
|
||||
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: ready
|
||||
flavor: implementation
|
||||
owner: claude
|
||||
topic_slug: railiance
|
||||
created: "2026-10-21"
|
||||
updated: "2026-10-21"
|
||||
related:
|
||||
- CUST-WP-0071
|
||||
- RESOURCE-WP-0008
|
||||
---
|
||||
|
||||
# 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: wait
|
||||
priority: medium
|
||||
needs_human: true
|
||||
blocking_reason: "Wave-2 cluster write; founder approval for wave 2 not yet given (2026-10-21 interview)"
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue