The `forge` machine: the template's first service VM #25

New issue

Closed

opened 2026-10-07 05:08:04 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-07 05:08:04 +01:00

The public templates gain a forge machine, the first service VM, so a forge-less deployment has somewhere for its Forgejo VM to be described. This is the machine facts alone: nothing provisions it until the profile, identity and builder-seam halves land.

Primary goals:

A forge machine — type = "service", runtime = "libvirt", its own address and MAC on the guest network, with forge_key = null and repos = [] as the type requires.
A required data disk — data_disk = { path; size_gb; }, sized by what a template forge's repositories plausibly need rather than by the existing guests' disks, since this is the one disk a reprovision keeps.
The diagnostics finally run against a real entry — allod check passes with the machine present, which exercises the service rules allod/inventory#24 added against template data instead of only against mutation fixtures.

Current state and specifics

allod/inventory#24 taught inventory to accept type = "service" and to require data_disk on one, refuse forge_key, and refuse repositories. No machine in the template is a service VM, so every one of those rules has so far only ever been exercised by a sabotage fixture.

machines is a literal attrset in flake.nix; allod-dev is 192.0.2.10 / 52:54:00:00:00:10 and privacy-1 is 192.0.2.11 / 52:54:00:00:00:11, so forge continues that sequence.

scripts/vm-specs.json is generated from the machine set and is what new-vm reads to attach the data disk at serial allod-data, which allod/nexus already supports, so no script change is needed for the disk to reach the guest.

Scope

In: the forge machine entry, and whatever its presence requires to keep allod check green. Out, each its own issue: the profile that composes Forgejo (allod/profiles), the identity and host key (allod/secrets), the builder seam that lets a profile compose a framework module (allod/archetypes), and forge-bootstrap (allod/nexus).

Part of allod/strategy#65

The public templates gain a `forge` machine, the first `service` VM, so a forge-less deployment has somewhere for its Forgejo VM to be described. This is the machine facts alone: nothing provisions it until the profile, identity and builder-seam halves land. Primary goals: - **A `forge` machine** — `type = "service"`, `runtime = "libvirt"`, its own address and MAC on the guest network, with `forge_key = null` and `repos = []` as the type requires. - **A required data disk** — `data_disk = { path; size_gb; }`, sized by what a template forge's repositories plausibly need rather than by the existing guests' disks, since this is the one disk a reprovision keeps. - **The diagnostics finally run against a real entry** — `allod check` passes with the machine present, which exercises the `service` rules allod/inventory#24 added against template data instead of only against mutation fixtures. ### Current state and specifics allod/inventory#24 taught inventory to accept `type = "service"` and to require `data_disk` on one, refuse `forge_key`, and refuse repositories. No machine in the template is a service VM, so every one of those rules has so far only ever been exercised by a sabotage fixture. `machines` is a literal attrset in `flake.nix`; `allod-dev` is `192.0.2.10` / `52:54:00:00:00:10` and `privacy-1` is `192.0.2.11` / `52:54:00:00:00:11`, so `forge` continues that sequence. `scripts/vm-specs.json` is generated from the machine set and is what `new-vm` reads to attach the data disk at serial `allod-data`, which `allod/nexus` already supports, so no script change is needed for the disk to reach the guest. ### Scope In: the `forge` machine entry, and whatever its presence requires to keep `allod check` green. Out, each its own issue: the profile that composes Forgejo (`allod/profiles`), the identity and host key (`allod/secrets`), the builder seam that lets a profile compose a framework module (`allod/archetypes`), and `forge-bootstrap` (`allod/nexus`). Part of allod/strategy#65

vnprc-agent referenced this issue from allod/strategy

2026-10-07 05:08:19 +01:00

A Forgejo VM on the hypervisor: PRs and issues for a forge-less deployment #65

~~vnprc-agent referenced this issue from allod/deploy 2026-10-07 16:13:16 +01:00~~

getting-started.sh leaves a new machine on the documentation subnet, and reports success #10