Define the managed service machine architecture #45

New issue

Open

opened 2026-09-04 01:26:21 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-09-04 01:26:21 +01:00

Contributor

Managed service machines need one composition model whether they run under a local hypervisor or on externally provided hardware.

Primary goals

Separate reusable service behavior from machine profiles and placement details.
Give inventory a common machine schema with explicit placement-specific data instead of assuming every managed machine is a VM.
Keep archetypes focused on profile composition while allowing service profiles to consume arbitrary application modules.
Administer initial provisioning, routine deployment, verification, and operator-invoked generation rollback from Nexus.
Prove the design with a synthetic stateless service machine without adding a generic stateful-service framework.

Direction

Create allod/services as the public library for reusable NixOS service modules and operational policy. It must not contain concrete machines, application-specific deployment flakes, identities, secrets, or deploy state. Generic public-host and static-site behavior can move there; site generators and content builds remain with their consumers.

Keep the service builder in allod/archetypes: archetypes compose profiles, and a service profile is defined by the application module it consumes rather than by whether it is stateful. Inventory will describe common machine facts plus a discriminated placement. Existing libvirt and microVM consumers must remain compatible while external KVM placement is added without fake runtime, hypervisor, MAC, or volume facts.

Nexus remains the operator surface for every managed machine. A fresh install and a routine deployment are distinct operations. Recovery favors rebuilding from declared configuration, restoring explicitly declared durable state, and reconnecting clients. Cheap operator-selected NixOS generation rollback remains useful for configuration failures, but does not imply application-data rollback.

Scope

This issue tracks the cross-repository framework work in allod/strategy, allod/services, allod/inventory, allod/archetypes, allod/profiles, allod/vm, and allod/nexus. It includes compatibility migrations and a synthetic end-to-end example.

Plan: allod/strategy/dev-plans/managed-service-machines.md on master.

Concrete deployments, provider accounts, DNS, private addressing, identities, secrets, application data, backup schedules, and live rollout are downstream concerns. Stateful-service continuity machinery is deferred until measured requirements and a second real consumer justify a shared abstraction.

Related: allod/nexus#39, allod/memory#47, and the superseded experiment recorded in allod/archetypes#60.

Managed service machines need one composition model whether they run under a local hypervisor or on externally provided hardware. ## Primary goals - Separate reusable service behavior from machine profiles and placement details. - Give inventory a common machine schema with explicit placement-specific data instead of assuming every managed machine is a VM. - Keep archetypes focused on profile composition while allowing service profiles to consume arbitrary application modules. - Administer initial provisioning, routine deployment, verification, and operator-invoked generation rollback from Nexus. - Prove the design with a synthetic stateless service machine without adding a generic stateful-service framework. ## Direction Create `allod/services` as the public library for reusable NixOS service modules and operational policy. It must not contain concrete machines, application-specific deployment flakes, identities, secrets, or deploy state. Generic public-host and static-site behavior can move there; site generators and content builds remain with their consumers. Keep the service builder in `allod/archetypes`: archetypes compose profiles, and a service profile is defined by the application module it consumes rather than by whether it is stateful. Inventory will describe common machine facts plus a discriminated placement. Existing libvirt and microVM consumers must remain compatible while external KVM placement is added without fake runtime, hypervisor, MAC, or volume facts. Nexus remains the operator surface for every managed machine. A fresh install and a routine deployment are distinct operations. Recovery favors rebuilding from declared configuration, restoring explicitly declared durable state, and reconnecting clients. Cheap operator-selected NixOS generation rollback remains useful for configuration failures, but does not imply application-data rollback. ## Scope This issue tracks the cross-repository framework work in `allod/strategy`, `allod/services`, `allod/inventory`, `allod/archetypes`, `allod/profiles`, `allod/vm`, and `allod/nexus`. It includes compatibility migrations and a synthetic end-to-end example. Plan: `allod/strategy/dev-plans/managed-service-machines.md` on master. Concrete deployments, provider accounts, DNS, private addressing, identities, secrets, application data, backup schedules, and live rollout are downstream concerns. Stateful-service continuity machinery is deferred until measured requirements and a second real consumer justify a shared abstraction. Related: `allod/nexus#39`, `allod/memory#47`, and the superseded experiment recorded in `allod/archetypes#60`.