72 lines
3.2 KiB
Markdown
72 lines
3.2 KiB
Markdown
---
|
|
id: STATE-WP-0091
|
|
type: workplan
|
|
title: "Check release headroom and retain a capacity allocation handoff"
|
|
domain: infotech
|
|
repo: state-hub
|
|
status: finished
|
|
owner: codex
|
|
topic_slug: infotech
|
|
created: "2026-09-10"
|
|
updated: "2026-09-14"
|
|
related: [STATE-WP-0090, RCLUSTER-WP-0014, RESOURCE-WP-0003, HFACT-WP-0001]
|
|
state_hub_workstream_id: "4c64d6a6-554d-5b16-a533-9be407fa6515"
|
|
---
|
|
|
|
Residual from STATE-WP-0090: revision 61 failed with Insufficient CPU even though
|
|
runtime usage was modest. Revision 63 succeeded after a measured same-service
|
|
MCP request adjustment. The single 4,000m node still reserves 3,895m (97.4%),
|
|
leaving 105m against a 100m API surge. Existing cluster collection and portfolio
|
|
contracts are finished inputs, not workplans to reopen. No factory capacity
|
|
admission follows from this release.
|
|
|
|
## Check scheduling headroom before State Hub promotion
|
|
|
|
```task
|
|
id: STATE-WP-0091-T01
|
|
status: done
|
|
priority: high
|
|
state_hub_task_id: "f84c0f1b-3354-5466-a239-ef9ef85daa07"
|
|
```
|
|
|
|
Add a read-only preflight to the existing promotion path. Reuse Kubernetes and
|
|
railiance-cluster capacity evidence; check effective pod requests, init/overhead,
|
|
placement constraints, rollout surge and migration-hook ordering. Report observed
|
|
freshness, remaining CPU/memory and precise insufficient-capacity reasons before
|
|
starting Helm. Do not claim a scheduling guarantee from an aggregate sum or lower
|
|
requests automatically. Prove the observed 65m refusal and 105m narrowly sufficient
|
|
case, including unrelated concurrent demand. Keep atomic rollback.
|
|
|
|
## Review sustained service demand and hand off shared capacity
|
|
|
|
```task
|
|
id: STATE-WP-0091-T02
|
|
status: done
|
|
priority: high
|
|
state_hub_task_id: "a433e2d3-6fd4-5313-9273-e3769c2cefeb"
|
|
```
|
|
|
|
State Hub owns its workload demand and release requirement. Check MCP latency,
|
|
errors, CPU contention and coverage after the 50m-to-10m request change; its 500m
|
|
limit, memory and replicas remain unchanged. The initial 1,078 five-minute samples
|
|
are partial coverage, not a full week. Propose a durable release margin and hand
|
|
any shared allocation or provisioning change to live records with railiance-cluster,
|
|
railiance-platform and resource-control using their existing authority contracts.
|
|
Include HFACT T01/T04 factory demand, other zero-request workloads and host usage;
|
|
current aggregate reservation alone is not capacity admission. No unrelated
|
|
allocation, procurement or scaling is authorized by this workplan. Close only
|
|
after the repeatable preflight and explicit receiving work records are verified.
|
|
|
|
Evidence: docs/evidence/2026-09-10-projection-convergence.json.
|
|
|
|
**T01 done 2026-09-14.** `scripts/release_headroom_preflight.py` plus
|
|
`make railiance-state-hub-headroom`. Fixtures prove 65m refuse, 105m narrow
|
|
pass, and 105m+50m pending refuse. Helm is not started; requests are not
|
|
lowered; `--atomic` remains required.
|
|
|
|
**T02 done 2026-09-14.** Existing 1,078 samples remain partial coverage.
|
|
Durable margin: remaining must cover 100m API surge and must refuse when
|
|
unrelated pending demand consumes the 5m sliver. Not factory admission.
|
|
Receiving records: `RAIL-BS-WP-0014`, `RESOURCE-WP-0007`, `RPF-WP-0041`.
|
|
`CUST-WP-0071` keeps weekly fleet review. Details:
|
|
`docs/evidence/2026-09-14-release-headroom.md`.
|