bootstrap-vm: inject and refresh host-provided repos from the hypervisor instead of cloning them on the guest #73

New issue

Closed

opened 2026-10-01 16:27:17 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-10-01 16:27:17 +01:00

bootstrap-vm puts a host-provided repo on the guest from the hypervisor's own checkout, and refreshes it the same way, instead of asking the guest to clone a remote its forge identity may not read.

Part of allod/strategy#62.

Primary goals:

The guest step skips host-provided repos — bootstrap-vm reads the machine's host-provided marker from vm-specs.json and leaves those repos out of the triples it hands bootstrap-vm-guest.sh, so the guest clone loop no longer dies on them under set -e.
A host step injects them — after the guest step, bootstrap-vm puts the hypervisor's checkout of each host-provided repo at ~/work/<checkout> on the guest over the existing ~/.ssh/host channel, refusing loudly rather than overwriting a guest tree that has local changes.
Repair refreshes, verify still checks — verify-vm --repair reruns the same step, so the guest copy follows the hypervisor's; lib/vm-health-check.sh needs no change because the checkout exists at its declared path.
The guest copy is recognizable — the injected checkout carries no origin, so guest tools can skip it by inspection; that rule is the contract the allod/tools child builds on.

Current state and specifics

scripts/bootstrap-vm-guest.sh renders one clone_or_pull per repo and runs them under set -euo pipefail on the guest with the guest's forge key (FORGE_SSH_CMD), so a repo the guest identity cannot read ends the bootstrap at that line and every repo after it is skipped. scripts/bootstrap-vm builds the triples from vm-specs.json .repos through lib/resolve-repos.sh and has no notion of a repo the host should supply; scripts/provision-vm runs bootstrap-vm then verify-vm, so such a machine cannot be provisioned at all today. The hypervisor already holds a checkout of every registry repo at its registry path, and the host-to-guest ssh identity is the one rebuild-vm and bootstrap-vm use.

Transport, to decide here: git push from the hypervisor to ssh://<guest>/~/work/<checkout> with receive.denyCurrentBranch=updateInstead set on a guest-side git init, which refuses a dirty working tree with a clear message; or git bundle create plus scp and a guest-side clone or fetch. The push is simpler to make idempotent; the bundle is what deployments already do by hand.

Scope

In scope: bootstrap-vm, bootstrap-vm-guest.sh argument handling, docs/provisioning-scripts.md, and tests for the skip and the refresh. The marker's name and vm-specs.json rendering belong to the allod/inventory child and should be settled first or in the same PR series. Out of scope: rebuild-vm running the verifier (allod/nexus#71) and the activation warning (allod/archetypes#127).

`bootstrap-vm` puts a host-provided repo on the guest from the hypervisor's own checkout, and refreshes it the same way, instead of asking the guest to clone a remote its forge identity may not read. Part of allod/strategy#62. Primary goals: - **The guest step skips host-provided repos** — `bootstrap-vm` reads the machine's host-provided marker from `vm-specs.json` and leaves those repos out of the triples it hands `bootstrap-vm-guest.sh`, so the guest clone loop no longer dies on them under `set -e`. - **A host step injects them** — after the guest step, `bootstrap-vm` puts the hypervisor's checkout of each host-provided repo at `~/work/<checkout>` on the guest over the existing `~/.ssh/host` channel, refusing loudly rather than overwriting a guest tree that has local changes. - **Repair refreshes, verify still checks** — `verify-vm --repair` reruns the same step, so the guest copy follows the hypervisor's; `lib/vm-health-check.sh` needs no change because the checkout exists at its declared path. - **The guest copy is recognizable** — the injected checkout carries no `origin`, so guest tools can skip it by inspection; that rule is the contract the allod/tools child builds on. ### Current state and specifics `scripts/bootstrap-vm-guest.sh` renders one `clone_or_pull` per repo and runs them under `set -euo pipefail` on the guest with the guest's forge key (`FORGE_SSH_CMD`), so a repo the guest identity cannot read ends the bootstrap at that line and every repo after it is skipped. `scripts/bootstrap-vm` builds the triples from `vm-specs.json` `.repos` through `lib/resolve-repos.sh` and has no notion of a repo the host should supply; `scripts/provision-vm` runs `bootstrap-vm` then `verify-vm`, so such a machine cannot be provisioned at all today. The hypervisor already holds a checkout of every registry repo at its registry path, and the host-to-guest ssh identity is the one `rebuild-vm` and `bootstrap-vm` use. Transport, to decide here: `git push` from the hypervisor to `ssh://<guest>/~/work/<checkout>` with `receive.denyCurrentBranch=updateInstead` set on a guest-side `git init`, which refuses a dirty working tree with a clear message; or `git bundle create` plus `scp` and a guest-side clone or fetch. The push is simpler to make idempotent; the bundle is what deployments already do by hand. ### Scope In scope: `bootstrap-vm`, `bootstrap-vm-guest.sh` argument handling, `docs/provisioning-scripts.md`, and tests for the skip and the refresh. The marker's name and `vm-specs.json` rendering belong to the allod/inventory child and should be settled first or in the same PR series. Out of scope: `rebuild-vm` running the verifier (allod/nexus#71) and the activation warning (allod/archetypes#127).

vnprc-agent referenced this issue from allod/strategy

2026-10-01 16:28:11 +01:00

Host-provided repos: inject and refresh a checkout from the hypervisor when the guest may not read its remote #62