Add service archetype for always-on LAN service VMs (first consumer: buzz relay stack) #15
Labels
No labels
blocked
bug
decision
duplicate
enhancement
help wanted
invalid
landed?
question
ready-to-merge
stale
wontfix
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
allod/archetypes#15
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Add a service archetype so the framework can compose small headless always-on VMs that serve other machines on the local network, with the buzz relay stack as the first consumer.
Primary goals:
inventory.lib.supportedPlatforms, never local system lists.Current state
The archetype layer stubs this class today:
flake.nix:298carries# mkServiceVm = TBD when first service VM is added. Evaluation numbers for sizing the first consumer: the buzz stack idles around 225MB total (relay 34MB, Postgres 30MB, Redis 9MB, MinIO 152MB). Relay behaviors the module must own: S3 is mandatory at boot (a git object-store conformance probe gates startup), search defaults to Postgres FTS so no extra search service is needed, and the relay binds a WebSocket/web port plus separate health (8080) and metrics (9102) listeners, so the archetype firewall must scope exposure per machine.Scope
In scope: archetype merge support and shared modules for the service class, the buzz package and service module, one synthetic example machine, and checks — all in this repo and its profiles input. Out of scope, owned by downstream deploy forks: concrete machines and addressing, key material, backups, and rollout sequencing. The public dev plan for this work lands in allod/strategy dev-plans and links back here.
Superseded in part. The first goal here — a
servicearchetype class — is now owned byallod/strategy#45andallod/strategy/dev-plans/managed-service-machines.md, which is the source of truth for managed service machine architecture.Two things changed since this was written.
A
servicearchetype was built against the shape described here, reviewed four times, and abandoned —allod/archetypes#60, closed as not planned. The finding was that a builder in this repo is the join of inventory, secrets, and profiles, and the machine it was being built for had none of the three legs.allod/strategy#45then re-approaches it from the other end: generalise inventory around a discriminated placement first (its M2), somkServicehas something honest to read, and make the archetype application-agnostic rather than shaped around one consumer (its M3). That plan also states directly thatdev-plans/buzz-service-archetype.mdmust not be executed as written, because its VM-only inventory and application-specific archetype assumptions are superseded.What survives here and is not tracked elsewhere: the buzz package at a pinned rev, the relay service module with its production-hardened defaults, the sizing and listener facts in "Current state", and the synthetic example machine. That work resumes as a consumer of the interfaces
allod/strategy#45defines, not as the thing that defines them.Leaving this open rather than closing it —
allod/strategy#45M5 owns the decision to rebase this work or close it as superseded, and that milestone has not started.