Accept type = service: a hypervisor guest whose state lives on a required data disk #24

New issue

Closed

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

vnprc-agent commented

2026-10-07 02:21:08 +01:00

A hypervisor guest that runs one network service for the rest of the fleet and keeps its state across reprovisioning can be described in inventory once type = "service" is a valid machine type with the shape rules that make it safe. Part of allod/strategy#65 (the forge VM is the first such machine) and the first, hypervisor-placed step of allod/strategy#45's service archetype; the builder lands in allod/archetypes and the identity in allod/secrets under their own issues.

Primary goals:

A fourth machine type — service beside dev, privacy and hypervisor. It is a guest: runtime is required, host, data_disk and host_provided_repos follow the guest rules, and vmSpecsJson carries it like any other guest.
A data disk is required — a service machine without data_disk fails evaluation with its own diagnostic. The disk is where every byte of the machine's state lives (the guest mounts all of /var/lib on it), so a service machine without one would lose everything on provision-vm --replace.
No forge access, no clones — forge_key must be null and repos must be empty on a service machine, each refused by its own diagnostic. A service machine holds no credential and checks nothing out; what it serves arrives through its profile.
Mutation fixtures — one fixture per new diagnostic in data-disk-fact-mutations or a sibling check, each tripping exactly its own diagnostic and no other, plus a valid service machine surviving into the generated spec. The template fleet itself is unchanged here; the forge machine arrives with allod/strategy#65's next slice.

Current state and specifics

flake.nix classifies machines in machineDiagnostics, one disjoint diagnostic set per rule, and mkVmSpecs asserts them; runtimeFreeTypes is [ "hypervisor" ] and type is otherwise unconstrained beyond being a string. The README's schema table lists type as dev, privacy, or hypervisor. data_disk is already an optional guest fact with its own diagnostics and the data-disk-fact-mutations check; this issue adds the rule that makes it mandatory for one type.

The service name was used once before for a rented host and withdrawn (allod/inventory#15, allod/archetypes#60); the comment at runtimeFreeTypes records that. This type is the opposite shape: a guest of this fleet with a runtime, so runtimeFreeTypes does not change and that comment is updated to say the name now means a stateful guest.

Scope

In: the type, the three diagnostics, their fixtures, the README table and the vmSpecsJson behaviour. Out: the archetypes builder, the secrets identity, any template machine, and allod/strategy#45's placement generalization.

A hypervisor guest that runs one network service for the rest of the fleet and keeps its state across reprovisioning can be described in inventory once `type = "service"` is a valid machine type with the shape rules that make it safe. Part of allod/strategy#65 (the forge VM is the first such machine) and the first, hypervisor-placed step of allod/strategy#45's service archetype; the builder lands in `allod/archetypes` and the identity in `allod/secrets` under their own issues. Primary goals: - **A fourth machine type** — `service` beside `dev`, `privacy` and `hypervisor`. It is a guest: `runtime` is required, `host`, `data_disk` and `host_provided_repos` follow the guest rules, and `vmSpecsJson` carries it like any other guest. - **A data disk is required** — a service machine without `data_disk` fails evaluation with its own diagnostic. The disk is where every byte of the machine's state lives (the guest mounts all of `/var/lib` on it), so a service machine without one would lose everything on `provision-vm --replace`. - **No forge access, no clones** — `forge_key` must be `null` and `repos` must be empty on a service machine, each refused by its own diagnostic. A service machine holds no credential and checks nothing out; what it serves arrives through its profile. - **Mutation fixtures** — one fixture per new diagnostic in `data-disk-fact-mutations` or a sibling check, each tripping exactly its own diagnostic and no other, plus a valid service machine surviving into the generated spec. The template fleet itself is unchanged here; the `forge` machine arrives with allod/strategy#65's next slice. ### Current state and specifics `flake.nix` classifies machines in `machineDiagnostics`, one disjoint diagnostic set per rule, and `mkVmSpecs` asserts them; `runtimeFreeTypes` is `[ "hypervisor" ]` and `type` is otherwise unconstrained beyond being a string. The README's schema table lists `type` as `dev`, `privacy`, or `hypervisor`. `data_disk` is already an optional guest fact with its own diagnostics and the `data-disk-fact-mutations` check; this issue adds the rule that makes it mandatory for one type. The `service` name was used once before for a rented host and withdrawn (allod/inventory#15, allod/archetypes#60); the comment at `runtimeFreeTypes` records that. This type is the opposite shape: a guest of this fleet with a `runtime`, so `runtimeFreeTypes` does not change and that comment is updated to say the name now means a stateful guest. ### Scope In: the type, the three diagnostics, their fixtures, the README table and the `vmSpecsJson` behaviour. Out: the archetypes builder, the secrets identity, any template machine, and allod/strategy#45's placement generalization.

vnprc-agent referenced this issue from allod/strategy

2026-10-07 02:21:45 +01:00

Define the managed service machine architecture #45

vnprc-agent referenced this issue

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

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

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