154 lines
5.4 KiB
Markdown
154 lines
5.4 KiB
Markdown
# First-Wave Reef Source Map
|
|
|
|
Date: 2026-07-25
|
|
|
|
## Purpose
|
|
|
|
Prepare the S1 source-backed handoff for the first reef rollout without turning
|
|
`railiance-infra` into a second reef repo family.
|
|
|
|
This document records:
|
|
|
|
- why `railiance-infra` is the canonical S1 source for reef creation
|
|
- which substrate facts are already stable enough to seed the first reefs
|
|
- which labels or future interpretations must remain provisional
|
|
|
|
This follows
|
|
`/home/worsch/railiance-master/docs/reef-first-wave-rollout.md`.
|
|
|
|
## Canonical S1 Stance
|
|
|
|
For future architecture work:
|
|
|
|
- `railiance-infra` is the canonical S1 ownership repo
|
|
- `railiance-hosts` is a predecessor or compatibility duplicate, not a second
|
|
authority for new reef planning
|
|
- future `reef-*` repos should project from the source-backed facts here rather
|
|
than recreate their own incompatible substrate inventories
|
|
|
|
Practical rule:
|
|
|
|
- use `inventory/servers.yaml` as the starting identity source for server reefs
|
|
- use S1 docs and operator-runbook facts for grouped workstation reefs
|
|
- treat legacy `railiance-hosts` references in historical ADRs, inbox evidence,
|
|
and archived workplans as historical context, not as current authority
|
|
|
|
## Stable Source Files
|
|
|
|
The current first-wave reef rollout should anchor on these files:
|
|
|
|
- `inventory/servers.yaml`
|
|
- `ansible/inventory/host_vars/CoulombCore.yml`
|
|
- `docs/deploy-stack.md`
|
|
- `docs/age-keys.md`
|
|
- `docs/adr/ADR-003-railiance-5repo-stack-architecture.md`
|
|
- `docs/adr/ADR-004-forgejo-in-cluster-actions-runner.md`
|
|
|
|
These files are not a complete future reef schema, but they already provide the
|
|
minimum operational facts needed to seed the first reef repos.
|
|
|
|
## First-Wave Reef Source Map
|
|
|
|
### `reef-railiance`
|
|
|
|
Stable facts available now:
|
|
|
|
- current first member: `Railiance01`
|
|
- current member IP: `92.205.62.239`
|
|
- current member SSH user: `tegwick`
|
|
- authoritative source today: `inventory/servers.yaml`
|
|
- current role in the ecosystem: the clearest home for new Kubernetes-first
|
|
production-oriented workloads
|
|
- operational evidence in this repo: ADR-004 records Forgejo production and
|
|
Actions runner placement on `railiance01`
|
|
- primary rail stance for first rollout: `rail-kubernetes`
|
|
- grouped-home intent: additional Railiance servers should be represented here
|
|
when they share the same home substrate lifecycle and workload-placement
|
|
policy
|
|
|
|
Known gaps that must stay explicit:
|
|
|
|
- only one source-backed member (`Railiance01`) is recorded today
|
|
- no dedicated `host_vars/Railiance01.yml` exists yet
|
|
- whether later `rail-knative` shares this reef or warrants separation remains
|
|
a workload- and security-driven decision
|
|
|
|
### `reef-coulombcore`
|
|
|
|
Stable facts available now:
|
|
|
|
- server identity: `CoulombCore`
|
|
- IP: `92.205.130.254`
|
|
- SSH user: `tegwick`
|
|
- authoritative source today: `inventory/servers.yaml`
|
|
- host-specific S1 operational facts already recorded in
|
|
`ansible/inventory/host_vars/CoulombCore.yml`
|
|
- `docs/deploy-stack.md` still treats CoulombCore as an active operator access
|
|
and execution point for convergence and stack bring-up
|
|
- ops-bridge naming already distinguishes `state-hub-coulombcore`
|
|
|
|
Operational interpretation for rollout:
|
|
|
|
- create it as a transitional reef
|
|
- keep mixed-purpose and fallback realities visible instead of pretending it is
|
|
already the preferred long-term home
|
|
|
|
### `reef-ops-workstations`
|
|
|
|
Stable facts available now:
|
|
|
|
- this is a grouped substrate class, not a permanent singleton machine
|
|
- age private keys stay on operator workstations; see `docs/age-keys.md`
|
|
- ops-bridge and attended control-plane access originate from the workstation;
|
|
see `docs/deploy-stack.md`
|
|
- kubeconfig use, SSH key custody, and attended control actions are currently
|
|
workstation responsibilities rather than server responsibilities
|
|
|
|
Operational interpretation for rollout:
|
|
|
|
- model this as operator or edge compute
|
|
- keep machine membership inside reef-local topology rather than creating one
|
|
repo per laptop
|
|
|
|
## Stable Facts Versus Provisional Labels
|
|
|
|
Stable now:
|
|
|
|
- the first-wave reef set:
|
|
- `reef-railiance`
|
|
- `reef-coulombcore`
|
|
- `reef-ops-workstations`
|
|
- `railiance-infra` as canonical S1 ownership source
|
|
- inventory-backed server identity for `Railiance01` and `CoulombCore`
|
|
- operator workstation responsibilities for age key custody, bridge usage, and
|
|
attended control-plane actions
|
|
- `rail-kubernetes` as the first primary rail stance for `reef-railiance`
|
|
- `Railiance01` as the first current member of the grouped Railiance home reef
|
|
|
|
Provisional for now:
|
|
|
|
- the future member set beyond `Railiance01`
|
|
- whether `rail-knative` should share `reef-railiance` or later move to a
|
|
separate reef
|
|
- narrative labels such as "associate", "sidecar", or "comet"
|
|
- any claim that CoulombCore has a settled long-term role beyond being an
|
|
active transitional substrate
|
|
|
|
## Handoff For First Reef Creation
|
|
|
|
Each first-wave reef repo should start with:
|
|
|
|
- substrate identity from the source-backed facts above
|
|
- declared substrate kind:
|
|
- `server-group` for `reef-railiance`
|
|
- `server` for `reef-coulombcore`
|
|
- `workstation-group` for `reef-ops-workstations`
|
|
- lifecycle stance:
|
|
- primary grouped home-reef seed for `reef-railiance`
|
|
- transitional legacy or fallback reef for `reef-coulombcore`
|
|
- grouped operator-edge reef for `reef-ops-workstations`
|
|
- initial primary rail statement where applicable
|
|
- explicit unresolved questions instead of invented certainty
|
|
|
|
That is enough to create the first reef repos without reopening the
|
|
`railiance-hosts` versus `railiance-infra` ambiguity.
|