Model a machine the fleet did not create: no runtime, x86 only, no hardware numbers #13

New issue

Closed

opened 2026-08-31 03:41:14 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-08-31 03:41:14 +01:00

Describe a machine the fleet did not create, so a rented internet-facing host can be registered without lying about how it came to exist.

Primary goals:

A rented host carries no runtime — and stating one is an error, matching the rule a hypervisor already lives under.
Service machines are x86_64-linux for now — refused early and legibly, rather than failing during provisioning.
No hardware numbers — a rented machine's size is not an instruction to anything.

Why this is needed

Every archetype builder reads its machine from machines.${name}. Two of those fields do not survive contact with a machine the fleet did not provision.

runtime names the virtualisation system running a machine as a guest — libvirt today — and the framework uses it to select the guest configuration that machine needs. A rented host has no honest answer: some provider's hypervisor runs it, nothing here can see or configure that, and there is no guest module to select.

The registry already models this. A hypervisor carries no runtime, and both directions are enforced: a guest missing one is an error, and a hypervisor carrying one is also an error. So "machine with no runtime" is an existing category rather than a new idea. Nexus is in it because it is bare metal; a rented host joins it for a different reason with the same consequence.

Decisions

One — runtime is absent for the service type, and present is an error. Widen the existing rule from "hypervisors carry no runtime" to "hypervisors and service machines carry no runtime". The rejected alternative was a runtime = "rented" value, which keeps every machine uniform at the cost of putting a fictional virtualisation system in a field that otherwise names real ones — something downstream will eventually try to look up a guest module for.

Note for later: this assumes a service is a rented host. A service running as a local guest is imaginable and is deliberately out of scope; when one appears, the decision is whether service splits by where it runs.

Two — a service machine's platform must be x86_64-linux, refused with a message that explains why. platform is the chip-and-operating-system pair the build targets, checked against the systems Nix exposes; it says nothing about who hosts the machine. Any value Nix knows would pass validation today, ARM included — and then the first ARM machine would fail somewhere confusing during provisioning, because every machine in this fleet is x86 and nothing here has ever built for another chip. Emulation is slow, a separate build machine is a machine, and building on the target needs the target running before it can be configured.

The constraint is close to free: x86 is what essentially every provider sells, and ARM is the patchy exception. So the door closes with a message naming the missing cross-architecture build path, and opens deliberately when someone wants it.

Three — no memory_mb, vcpus, disk_gb, or mac. For a guest these are instructions that the hypervisor acts on. For a rented machine they would be descriptions of what is being paid for, and nothing in the file distinguishes the two. Someone would eventually edit the memory size on a rented host and wonder why nothing happened. If a need for them appears, give them names that cannot be mistaken for the guest fields.

Scope

In scope: the schema rules above and fixtures proving each refusal fires.

Not in scope: any actual service machine entry. The first one is added when its host is rented, so the entry describes something real. The rules land first and are exercised by fixtures.

Related: the builder that consumes this is tracked in allod/archetypes.

Describe a machine the fleet did not create, so a rented internet-facing host can be registered without lying about how it came to exist. Primary goals: - **A rented host carries no `runtime`** — and stating one is an error, matching the rule a hypervisor already lives under. - **Service machines are `x86_64-linux` for now** — refused early and legibly, rather than failing during provisioning. - **No hardware numbers** — a rented machine's size is not an instruction to anything. ### Why this is needed Every archetype builder reads its machine from `machines.${name}`. Two of those fields do not survive contact with a machine the fleet did not provision. `runtime` names the virtualisation system running a machine as a guest — `libvirt` today — and the framework uses it to select the guest configuration that machine needs. A rented host has no honest answer: some provider's hypervisor runs it, nothing here can see or configure that, and there is no guest module to select. The registry already models this. A hypervisor carries no `runtime`, and both directions are enforced: a guest missing one is an error, and a hypervisor carrying one is also an error. So "machine with no runtime" is an existing category rather than a new idea. Nexus is in it because it is bare metal; a rented host joins it for a different reason with the same consequence. ### Decisions **One — `runtime` is absent for the `service` type, and present is an error.** Widen the existing rule from "hypervisors carry no runtime" to "hypervisors and service machines carry no runtime". The rejected alternative was a `runtime = "rented"` value, which keeps every machine uniform at the cost of putting a fictional virtualisation system in a field that otherwise names real ones — something downstream will eventually try to look up a guest module for. Note for later: this assumes a service is a rented host. A service running as a local guest is imaginable and is deliberately out of scope; when one appears, the decision is whether `service` splits by where it runs. **Two — a `service` machine's `platform` must be `x86_64-linux`, refused with a message that explains why.** `platform` is the chip-and-operating-system pair the build targets, checked against the systems Nix exposes; it says nothing about who hosts the machine. Any value Nix knows would pass validation today, ARM included — and then the first ARM machine would fail somewhere confusing during provisioning, because every machine in this fleet is x86 and nothing here has ever built for another chip. Emulation is slow, a separate build machine is a machine, and building on the target needs the target running before it can be configured. The constraint is close to free: x86 is what essentially every provider sells, and ARM is the patchy exception. So the door closes with a message naming the missing cross-architecture build path, and opens deliberately when someone wants it. **Three — no `memory_mb`, `vcpus`, `disk_gb`, or `mac`.** For a guest these are instructions that the hypervisor acts on. For a rented machine they would be descriptions of what is being paid for, and nothing in the file distinguishes the two. Someone would eventually edit the memory size on a rented host and wonder why nothing happened. If a need for them appears, give them names that cannot be mistaken for the guest fields. ### Scope In scope: the schema rules above and fixtures proving each refusal fires. Not in scope: any actual service machine entry. The first one is added when its host is rented, so the entry describes something real. The rules land first and are exercised by fixtures. Related: the builder that consumes this is tracked in `allod/archetypes`.