Fix dpdk build deps

This commit is contained in:
Audiobuzz
2026-06-14 06:12:35 +00:00
parent dbf0d075bc
commit 1a0cd5c37f
2 changed files with 39 additions and 0 deletions
+34
View File
@@ -113,3 +113,37 @@ boot LAN.
writable → multi-user.
- This validation **gates** item #1 (network-manager port) and item #3
(errata → design v3).
## [ ] 6. Rolling fleet updates (multi-version serve → cohort reboots)
Image-based, reboot-to-update across many live workstations. Hosts are immutable
(read-only erofs/verity root over NVMe/TCP, ephemeral overlay), so updates are
**atomic A/B reboots**, never in-place. The released OCI artifact + digest-pinned
manifest + roothash coupling already give the atomic unit and instant rollback;
this item builds the rollout machinery around it.
- **Serve versions side-by-side** (must not overwrite a live rootfs): extend
`serving/` so SPDK/nvmet exposes each release as its **own subsystem/NQN**
(`nqn…:rootfs-<ver>`) and nginx serves multiple `fleet-<ver>.efi` (keep
current + previous). Make the UKI's NQN version-specific so each signed UKI
connects only its matching namespace (constant discovery DNS name).
- **Version selection at boot**: dnsmasq **cohort tagging** (MAC / vendor class /
assigned tag) hands each cohort a different option-67 UKI URL. Moving a
cohort's URL = assigning the release.
- **Control plane + in-image reboot agent**: a baked-in systemd timer polls a
"desired version" endpoint and reboots **when idle / in a maintenance window**
(or out-of-band via Redfish/BMC). Stagger + jitter reboots to avoid UKI-fetch
/ NVMe-connect storms.
- **Staged rollout**: canary → waves (10/50/100%) with health gates
(multi-user reached, NVMe connected, dm-verity mapped, kiosk URL rendered,
prod: MACsec/802.1X up); auto-halt on threshold.
- **Rollback**: repoint cohort URL to previous UKI + reboot (current+previous
stay served); security rollback via dbx-revoke / TPM monotonic counter
(design §6).
- **Drain & retire** an old version only when SPDK/nvmet reports zero connected
controllers on it.
- **Availability**: run NVMe/TCP target replicas behind distinct discovery
entries (design §7) — never serve the whole fleet from one unreplicated node,
especially mid-rollout (N versions + reboot bursts).
- Note: kiosk *content* changes are server-side (the website) and need no fleet
update — only OS/UKI/rootfs changes require a reboot.