`staging` bootstrap role: host archetype for box-hosted staging VMs #22

New issue

Closed

opened 2026-07-17 15:46:08 +00:00 by dan-claude-bot · 0 comments

dan-claude-bot commented

2026-07-17 15:46:08 +00:00

(Migrated from github.com)

Context

The fleet's staging-server (M900) — the machine that hosts staging VMs, each registered in the control plane (Coolify) as a server — is bootstrapped ad-hoc today. This issue adds a first-class host archetype for it.

Design

Layering (companion box issue linked below):

New bootstrap role staging alongside control-plane / workload / runner: a machine whose job is to host staging boxes — Incus VMs minted by box (heavy-duty/box) from its new staging template — each of which is later converged from inside with rig bootstrap workload.
Role semantics: default hostname staging (convention: default = role name); default tag tag:local; hard-refuses tag:server (precedent: the runner role refuses tag:server) — hosts are never managed by the control plane, their guests are. The fleet has already been bitten once by a host wrongly carrying tag:server.
Deliberately minimal: the role does not install Incus or box — box's own setup-host owns Incus config (single owner; avoids two tools converging the same daemon). The role asserts /dev/kvm presence (warn, not fail — the box may be rehearsed in a container) and prints a next-step pointer to box's installer.
The guest needs zero rig changes: rig bootstrap workload is already the staging-box role (it is rehearsed inside Incus instances in the incubator migration runbook).
Anticipated follow-up (not this issue): a dev role for dev-box hosts — same plumbing, honest name, matching the existing precedent of near-identical roles kept distinct for name honesty (control-plane vs workload).

What changes

commands/bootstrap.sh: add staging to the role case; tag default tag:local; tag:server refusal; /dev/kvm advisory + box pointer in the closing log.
test/cli.sh: arg/refusal assertions (usage paths; staging + --ts-tag tag:server → exit 1 before any root check).
docs/plans/2026-07-17-staging-role.md: design/implementation plan per repo convention.
README.md: role table update.

Non-goals

No VM provisioning in rig — box owns minting.
No control-plane/Coolify API usage.
No dev role yet.

Acceptance

rig bootstrap staging --ts-tag tag:server exits 1 with a refusal, before the root check (testable as non-root).
rig bootstrap staging on a pristine Debian box converges: hardened sshd drop-in, tailnet join as tag:local, hostname set; second run is a no-op.
shellcheck and bash test/cli.sh green.

Companion box issue: https://github.com/heavy-duty/box/issues/68

## Context The fleet's `staging-server` (M900) — the machine that hosts staging VMs, each registered in the control plane (Coolify) as a server — is bootstrapped ad-hoc today. This issue adds a first-class host archetype for it. ## Design Layering (companion box issue linked below): - New bootstrap role **`staging`** alongside `control-plane` / `workload` / `runner`: a machine whose job is to *host* staging boxes — Incus VMs minted by `box` (heavy-duty/box) from its new `staging` template — each of which is later converged from inside with `rig bootstrap workload`. - Role semantics: default hostname `staging` (convention: default = role name); default tag **`tag:local`**; **hard-refuses `tag:server`** (precedent: the `runner` role refuses `tag:server`) — hosts are never managed by the control plane, their guests are. The fleet has already been bitten once by a host wrongly carrying `tag:server`. - Deliberately minimal: the role does **not** install Incus or box — box's own `setup-host` owns Incus config (single owner; avoids two tools converging the same daemon). The role asserts `/dev/kvm` presence (warn, not fail — the box may be rehearsed in a container) and prints a next-step pointer to box's installer. - The **guest** needs zero rig changes: `rig bootstrap workload` is already the staging-box role (it is rehearsed inside Incus instances in the incubator migration runbook). - Anticipated follow-up (not this issue): a `dev` role for dev-box hosts — same plumbing, honest name, matching the existing precedent of near-identical roles kept distinct for name honesty (`control-plane` vs `workload`). ## What changes 1. `commands/bootstrap.sh`: add `staging` to the role case; tag default `tag:local`; `tag:server` refusal; `/dev/kvm` advisory + box pointer in the closing log. 2. `test/cli.sh`: arg/refusal assertions (usage paths; `staging` + `--ts-tag tag:server` → exit 1 before any root check). 3. `docs/plans/2026-07-17-staging-role.md`: design/implementation plan per repo convention. 4. `README.md`: role table update. ## Non-goals - No VM provisioning in rig — box owns minting. - No control-plane/Coolify API usage. - No `dev` role yet. ## Acceptance - `rig bootstrap staging --ts-tag tag:server` exits 1 with a refusal, before the root check (testable as non-root). - `rig bootstrap staging` on a pristine Debian box converges: hardened sshd drop-in, tailnet join as `tag:local`, hostname set; second run is a no-op. - shellcheck and `bash test/cli.sh` green. --- Companion box issue: https://github.com/heavy-duty/box/issues/68

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/rig#22

No description provided.

staging bootstrap role: host archetype for box-hosted staging VMs #22