alexion
969737b6b5
Add a `nesting` placement field to the Host-side guest interface, a bool off by default. On, it grants the guest's container the prerequisites its interior needs to run Podman and other OCI containers: the `CAP_NET_ADMIN` capability an OCI runtime uses to build its bridges and firewall rules, and the `/dev/net/tun` and `/dev/fuse` device nodes it reaches for to network those containers and back their overlay storage. Off, both the capability and device lists are empty, so a non-nesting guest is untouched. cgroup delegation, the other nested prerequisite, the NixOS container backend already grants every container unconditionally, so the Skeleton records it with an absence pointer rather than re-emitting it. Add a nesting-sample guest whose interior defines an `oci-containers` workload on Podman, and enable it on neogaia with `nesting` on, so the path builds end to end through the Host's `nix flake check` — which pulls in podman and the generated container unit for the nested system.
3.3 KiB
spec, blocked-by
| spec | blocked-by |
|---|---|
| guests | 0002-guest-walking-skeleton |
What to build
The Host-side placement that makes the OCI fallback a plain Guest, so image-only software has a declarative home without a separate mechanism.
A Host sets nesting to grant the nested-container prerequisites so the Guest's interior can run Podman and other OCI containers.
The Skeleton emits the nested-container cgroup-delegation and capability prerequisites once, so the operator flips one boolean and the interior's oci-containers runtime works, with Podman as the default runtime.
Acceptance criteria
- A Host setting
guests.<path>.nestinggrants the nested-container cgroup-delegation and capability prerequisites, off by default. - With
nestingon, the Guest's interior can defineoci-containersrunning Podman as the default runtime. - With
nestingoff, those prerequisites are absent and the Guest is unaffected. - A Host with a nesting Guest that defines an OCI container builds via
nix flake check.
Implementation Notes
-
nestingis a Host-side placement field on the guest, a bool defaulting off, alongside the other placement fields inlib.nix. On, it grants the guest's containerCAP_NET_ADMINand the/dev/net/tunand/dev/fusedevice nodes, the capability and devices an OCI runtime reaches for to network its containers and back their overlay storage. Off, bothadditionalCapabilitiesandallowedDevicesare empty, matching the NixOS defaults, so a non-nesting guest is untouched. -
The capability prerequisite is
CAP_NET_ADMINalone. A container-backend guest runs privileged (privateUsers = "no"), so it already retains the broad nspawn capability set includingCAP_SYS_ADMIN; the one addition an OCI runtime needs is network administration for its bridges and firewall rules. -
cgroup delegation is not toggled by
nesting, a deliberate deviation from the criterion's wording that the flag "grants" it and that it is "absent" when off. The NixOS container backend setsDelegate = trueon every container's unit unconditionally, so the delegated cgroup subtree an OCI runtime manages is always present. Re-emitting it undernestingwould be redundant, and forcing it off for non-nesting guests to make it literally "absent" would remove a harmless, useful default for no gain. The Skeleton records the prerequisite as satisfied-elsewhere with an absence pointer comment, so a reader does not think delegation was forgotten. -
A new
guests/nesting-sample.nixcarries an interior that defines anoci-containersworkload, the payload the criteria exercise, andneogaiaenables it withnesting = true. This follows the walking-skeleton's precedent of proving a guest path through the one Host'snix flake check: the flake check builds the nestednixos-system-nesting-samplein full, pulling inpodmanand the generatedpodman-hello.serviceunit, which is how criteria two and four are verified on the build seam. The sample carries the same modest caps as the walking-skeleton guest so an interior container cannot starve the laptop. -
The two behaviors the build seam cannot prove — that the interior Podman actually starts a container and that its networking works — are left to manual verification on the target Host and to the VM integration test of task 0010, per the spec's testing decisions.