jakman85andClaude Opus 4.8
df5979fceb
The UniFi VM boot-disk DataVolume (RWX + Block on longhorn-vm) failed to import: CDI's non-root importer (UID 107, cap-drop ALL) hit `blockdev: cannot open /dev/cdi-block-volume: Permission denied`. Kubernetes only applies fsGroup ownership to *filesystem* volumes — it never chowns a raw block device — and Longhorn's CSIDriver (fsGroupPolicy: ReadWriteOnceWithFSType) skips fsGroup on RWX/Block volumes regardless, so the device stays root:root. The CDI-documented fix is the container-runtime setting `device_ownership_from_security_context`, exposed on k3s (>= v1.31.3+k3s1, this cluster is v1.31.5) as `nonroot-devices: true`. It makes containerd set the in-container device node's owner from the pod's securityContext. Added to the Ansible-managed /etc/rancher/k3s/config.yaml alongside tls-san; applied via the existing rolling `Restart k3s` handler (serial:1, kube-vip keeps the API up, etcd holds 2/3). Node-scoped, security-neutral (pods stay non-root), and preserves the longhorn-vm RWX/Block/migratable contract unchanged. Co-Authored-By: Claude Opus 4.8 <[email protected]>
apps
App-tier manifests, rendered from catalog/*.yaml ServiceDefinitions by catalog/render.py
and split into dependency-ordered waves (wave-<N>/).
- Each
wave-<N>/is reconciled by its own Flux Kustomizationapps-wave-<N>(clusters/base/apps-wave-<N>.yaml), whichdependsOnwave N-1 (wave 0 dependsOnplatform-config) and health-gates (wait: true) ONLY that wave. A crashlooping workload in a later wave can no longer stall an earlier wave or block new revisions. wave-<N>/kustomization.yamlandclusters/base/apps-wave-<N>.yamlare generated — runpython3 catalog/render.py --emit-wavesafter onboarding a service; do not hand-edit them.- Wave assignment = longest dependency-path depth over the catalog
dependencies:graph; a co-located CNPG database<svc>-dbis a leaf and always lands strictly below its consumer.
See ../DESIGN-waves.md for the wave table, Flux topology, and the
cutover runbook.