0 Fork 0

Files

T

jakman85andClaude Opus 4.8 317b3f02f1 feat(vms): onboard UniFi OS Server as a KubeVirt VM on a non-gating track

First KubeVirt VM app + first real CDI http import. UniFi OS Server (UOS) is
Ubiquiti's current self-host product (the .deb is deprecated); it bundles UniFi
OS + Network app + its own datastore, so no MongoDB companion.

- apps/vms/unifi: CDI DataVolume (Ubuntu 24.04 cloud image -> longhorn-vm
  RWX/Block, live-migratable) + VirtualMachine (evictionStrategy: LiveMigrate)
  with cloud-init that installs podman/slirp4netns/jq and runs the UOS installer
  NON-INTERACTIVELY. The installer URL is resolved at boot from Ubiquiti's public
  firmware API (fw-update.ui.com/api/firmware-latest) — always-latest, no pinned
  URL to maintain (currently UOS v5.1.37).
- L4 exposure: two LoadBalancer Services (TCP+UDP) sharing a pinned, L2-announced
  Cilium VIP 192.168.1.54 (device inform/adoption + STUN can't ride the L7
  Gateway); external-dns publishes unifi.home.keithjackson.dev. UI on :11443.
- default-deny + additive CNPs (controller ingress, egress, and CDI-importer
  egress for the image pull).
- clusters/base/apps-vms.yaml: NON-GATING Flux Kustomization (wait:false,
  dependsOn platform-config) — VMs are a separate lifecycle from the app waves,
  so a slow VM import/install can't stall the app tier.

Co-Authored-By: Claude Opus 4.8 <[email protected]>

2026-08-26 15:05:05 -05:00

vms

feat(vms): onboard UniFi OS Server as a KubeVirt VM on a non-gating track

2026-08-26 15:05:05 -05:00

wave-0

refactor(apps): split monolithic apps Kustomization into dependency waves

2026-08-26 12:19:00 -05:00

wave-1

refactor(apps): split monolithic apps Kustomization into dependency waves

2026-08-26 12:19:00 -05:00

wave-2

refactor(apps): split monolithic apps Kustomization into dependency waves

2026-08-26 12:19:00 -05:00

README.md

refactor(apps): split monolithic apps Kustomization into dependency waves

2026-08-26 12:19:00 -05:00

README.md

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 Kustomization apps-wave-<N> (clusters/base/apps-wave-<N>.yaml), which dependsOn wave N-1 (wave 0 dependsOn platform-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.yaml and clusters/base/apps-wave-<N>.yaml are generated — run python3 catalog/render.py --emit-waves after 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>-db is a leaf and always lands strictly below its consumer.

See ../DESIGN-waves.md for the wave table, Flux topology, and the cutover runbook.