a32a64454a
Verified against railiance01 on 2026-08-12 once API access was restored. Corrections: two clusters are managed, not one - railiance01 is the current primary running the live workloads, CoulombCore is the older frozen cluster. Traefik is the ingress controller, not nginx. ArgoCD is not on railiance01 at all; it runs on CoulombCore only, so the previous entry was accurate for that host but misleading as a general cluster-level claim. Adds the verified addon and CNPG cluster inventory, notes the absence of any monitoring stack, and points at RAIL-HO-WP-0009 for the source-restricted k3s API. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.6 KiB
| id | type | title | domain | repo | status | owner | topic_slug | created | updated | related | state_hub_workstream_id | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| RAIL-BS-WP-0014 | workplan | Publish cluster capacity, utilization, and allocation evidence | financials | railiance-cluster | ready | codex | railiance | 2026-08-11 | 2026-08-11 |
|
ea6ec98a-0d65-4afa-b6c5-6e7ed34011ac |
RAIL-BS-WP-0014 — cluster resource evidence
Goal
Publish reproducible non-secret evidence for
resource:railiance:reef-railiance:k3s: capacity, requested and observed
utilization, persistent-storage exposure, failure domains, and allocation
drivers. Origin: RESOURCE-WP-0003-T04 delegated evidence gap.
T01 — Produce periodic cluster capacity observations
id: RAIL-BS-WP-0014-T01
status: todo
priority: high
state_hub_task_id: "a144bf1d-0402-4526-9bda-17846390270c"
Collect node count, allocatable CPU/memory/storage/pods, workload requests and limits, observed usage when metrics are available, and PVC requested capacity. Aggregate by namespace/workload without exposing Secret data or pod environment. Preserve observation time, cluster identity, units, unavailable metrics, and source commands.
Done when repeated observations use a stable machine-readable interface and resource-control can distinguish headroom, reservations, and actual usage.
T02 — Publish the failure-domain and storage contract
id: RAIL-BS-WP-0014-T02
status: todo
priority: high
state_hub_task_id: "6460d9aa-3ded-420a-bf01-f0ccdeee0a02"
Expose the current node-to-host/provider failure-domain map and the actual
storage-class/PVC durability contract. Link the target ThreePhoenix work in
RAIL-BS-WP-0007 without reporting target nodes or distributed storage as
current capacity.
Done when consumers can calculate correlated-failure risk and recognize which
state remains local to railiance01.
T03 — Define technical allocation-driver evidence
id: RAIL-BS-WP-0014-T03
status: todo
priority: medium
state_hub_task_id: "e5ff9b6c-e883-4356-9eca-b31757661d2f"
Evaluate namespace/workload CPU-request hours, memory-request hours, PVC GB-month, and observed usage as allocation drivers. Publish numerator, denominator, residual/unallocated capacity, method version, and uncertainty; do not convert the result into booked spend.
Done when resource-control can create an explainable allocation and fin-hub can reconcile it to referenced financial facts.
Acceptance
- Capacity evidence separates allocatable, requested, limited, and observed.
- Current single-host/local-storage risk is machine-readable.
- Allocation drivers reconcile to explicit totals and residuals.