87 lines
4 KiB
Markdown
87 lines
4 KiB
Markdown
# INTENT — resource-control
|
|
|
|
## Why this repository exists
|
|
|
|
Railiance consumes compute, storage, network, and managed services from
|
|
external providers. Those resources create recurring cost, operational
|
|
dependencies, capacity limits, and switching decisions that cannot be managed
|
|
reliably from invoices, provider consoles, or deployment repositories alone.
|
|
|
|
`resource-control` is the control plane for that portfolio. It records what we
|
|
consume, why we consume it, who owns it, what it costs, how fully it is used,
|
|
and which procurement alternatives could provide a better combination of
|
|
cost, resilience, sovereignty, and operational fit.
|
|
|
|
The initial provider set is:
|
|
|
|
- **A — Host Europe**
|
|
- **B — Scaleway**
|
|
- **C — Hetzner**
|
|
|
|
The set is a comparison baseline, not a permanent allow-list. Adding a
|
|
provider requires evidence; retaining one requires continuing value.
|
|
|
|
## What it owns
|
|
|
|
- A provider-neutral inventory of purchased and proposed resources.
|
|
- Resource identity, provider, region, service class, capacity, lifecycle,
|
|
contract term, renewal/cancellation window, owner, workload, environment,
|
|
and cost-attribution key.
|
|
- Normalized recurring and usage-based cost, including storage, ingress,
|
|
egress, requests, support, taxes, minimum commitments, and switching cost.
|
|
- Demand forecasts and procurement research for new compute and storage.
|
|
- Utilization and saturation evidence linked to each resource.
|
|
- Budget-versus-actual reporting inputs for `fin-hub`.
|
|
- Periodic rightsizing, consolidation, commitment, migration, and provider
|
|
switching recommendations.
|
|
- Decision records and exit plans for material provider commitments.
|
|
|
|
## Relationship with fin-hub
|
|
|
|
`resource-control` answers **what concrete resources are bought, used, and
|
|
replaceable**. `fin-hub` answers **what the federation can afford, what its burn
|
|
rate and runway are, and when resource pressure must change priorities**.
|
|
|
|
This repo publishes normalized inventory, allocation, forecast, and realized
|
|
cost evidence to fin-hub. It does not create a competing budget ledger or
|
|
financial allocator.
|
|
|
|
## Operating principles
|
|
|
|
1. **Provider-neutral requirements first.** Define durability, recovery,
|
|
residency, performance, capacity, and exit requirements before comparing
|
|
product names.
|
|
2. **Total cost, not headline price.** Include traffic, requests, minimum
|
|
charges, tax, support, labor, migration, and recovery-test cost.
|
|
3. **No unowned spend.** Every resource has an accountable owner, workload,
|
|
environment, purpose, and cost-attribution key.
|
|
4. **No untested resilience claims.** Backup resources are accepted only after
|
|
a restore; compute failover is accepted only after a failover exercise.
|
|
5. **Exit is part of procurement.** Record data export, migration path,
|
|
cancellation window, and credential revocation before commitment.
|
|
6. **Avoid correlated failure silently.** Same-provider placement may be
|
|
intentional, but the shared failure domain and compensating control must be
|
|
explicit.
|
|
7. **Measure before optimizing.** Recommendations distinguish observed
|
|
utilization from estimates and assumptions.
|
|
8. **Credentials stay elsewhere.** Provider keys and billing credentials live
|
|
in the approved OpenBao/credential-broker lanes, never in this repository.
|
|
|
|
## What it does not own
|
|
|
|
- Budget authority, runway policy, or financial transactions (`fin-hub` and
|
|
human financial authority).
|
|
- Workload manifests and service-specific backup procedures (owning `rapp-*`
|
|
or workload repositories).
|
|
- Provider credentials or payment instruments.
|
|
- Cluster-wide deployment governance (`railiance-platform`).
|
|
- Application data retention policy, except to verify that procured resources
|
|
can satisfy it.
|
|
|
|
## Initial outcome
|
|
|
|
Procure and operationalize off-host object storage for `rapp-postgres`
|
|
continuous WAL archiving and physical base backups, while retaining a separate
|
|
logical-backup copy. The chosen resource must support a verified full restore
|
|
and point-in-time recovery, expose its real monthly cost and utilization to
|
|
fin-hub, and retain a tested provider-exit path.
|