jakman85andClaude Opus 5
f21e89d9d2
`platform-config` applied the CDI CR *and* cdi-storageprofiles.yaml in ONE pass.
StorageProfile's CRD does not exist until cdi-operator reconciles that CR, and
Flux server-side dry-runs every object before applying any — so the unknown kind
aborted the tier, the CR was never applied, the CRD was never created, and the
tier could NEVER converge. Observed on prod: cdi-operator Available 12h, no CDI
CR, no storageprofiles CRD, every downstream tier blocked.
The profiles now live in their own tier ./platform-config-cdi with
dependsOn: platform-config and wait: true. Because dependsOn is REVISION-gated
and platform-config runs wait: true, the CDI CR must be applied AND healthy —
exactly the event that creates the CRD — before the profiles are applied. Cold
clusters order themselves. `standup.sh crds` is retained as a fallback for
clusters already stuck, and because it is idempotent.
THE GENERALISABLE RULE (recorded in clusters/README.md): a CR whose CRD is
created by a CONTROLLER AT RUNTIME is second-order and needs its own pass.
cdi-operator.yaml registers exactly ONE CRD (cdis.cdi.kubevirt.io); storageprofiles,
datavolumes, datasources and dataimportcrons appear only after it reconciles the
CDI CR. An audit found StorageProfile is the only second-order kind in
platform-config — KubeVirt, CDI, KeycloakRealmImport, CNPG Cluster,
VolumeSnapshotClass, ClusterIssuer, PrometheusRule, ServiceMonitor and the Cilium
L2 CRs all have their CRD in git or in a chart.
Moving the CDI CR up into `platform` was rejected: that would put CDI's health on
the tier the CNI gates and everything waits on — the mistake the oauth2-proxy and
headlamp splits exist to undo.
apps-vms gains dependsOn: platform-config-cdi. LOAD-BEARING, not cosmetic:
apps/vms/unifi/20-datavolume.yaml provisions on storageClassName: longhorn-vm and
its comment claimed platform-config guaranteed the profiles — which this move
would have silently falsified.
THE PRUNE TRANSIENT, MEASURED RATHER THAN ASSUMED. platform-config has
prune: true, so it deletes both profiles once, CDI recreates them with empty spec,
and the new tier re-applies the overrides ~30-60s later. Compared our override
against CDI's unaided inference for the same Longhorn provisioner on dev:
longhorn-vm (we override) spec RWX/Block -> status ReadWriteMany/Block
longhorn-static (no override) spec unset -> status ReadWriteOnce/Block
Both infer cloneStrategy: snapshot. So cloneStrategy is NOT at risk; accessModes
IS — unaided CDI gives RWO. A DataVolume provisioned on longhorn-vm inside the
window would be stamped RWO/Block and be PERMANENTLY non-live-migratable. Flux can
no longer cause it (apps-vms gates on the new tier); a human must not do it by hand.
Corroborating evidence that the recreate happens at all: dev has 5 StorageClasses
and 5 StorageProfiles, three with fluxOwner=NONE, spec unset and status populated
— CDI creating and inferring them with no Flux involvement.
MERGE PRECONDITION: `flux get kustomization platform-config` must be Ready on the
target first. If it is not, the profiles are pruned and sit at CDI defaults until
it recovers — and prod was in that state hours earlier. Fallback is the two-step
the Cilium move used (merge with prune: false, verify the ownership label moved,
restore prune: true).
substituteFrom: cluster-vars is declared even though the manifest has no ${TOKEN},
deliberately: conformance/tests/l0-static/flux-postbuild-substitution only audits
paths whose Kustomization declares it, so omitting it would move the file OUT of
the audited set — a blind spot for a future literal-token ship. Gate confirms it
stayed in (path=./platform-config-cdi files=2 defined=0 hazards=0). No SOPS
decryption stanza: the moved file is two plain CRs, so no overlay change was needed.
VERIFIED INDEPENDENTLY OF THE AGENT: platform-config renders 0 StorageProfile
while keeping the CDI and KubeVirt CRs; platform-config-cdi renders exactly the
two profiles; the graph is byte-identical across dev and prod with apps-vms
carrying both edges and no cycle. Full CI gate PASS.
KNOWN FOLLOW-UP: bootstrap/standup.sh TIER_ORDER does not yet include
platform-config-cdi, so `resume` will not wait on it. Another agent holds that
file; the PM will add it.
Refs R-GITOPS-01, R-ENV-02.
Co-Authored-By: Claude Opus 5 <[email protected]>
57 lines
3.4 KiB
YAML
57 lines
3.4 KiB
YAML
---
|
|
# CDI StorageProfiles — the storage "recipes" CDI uses when it provisions/clones VM disk PVCs
|
|
# (ADR-0005).
|
|
#
|
|
# APPLIED BY `platform-config-cdi`, NOT `platform-config` (moved 2026-09-05). These are SECOND-ORDER
|
|
# CRs: `storageprofiles.cdi.kubevirt.io` is NOT registered by the CDI operator install (cdi-operator.yaml
|
|
# ships only `cdis.cdi.kubevirt.io`) — cdi-operator creates it only AFTER it has reconciled the `CDI` CR
|
|
# that platform-config applies. Flux server-side dry-runs every object in a pass before applying any of
|
|
# them, so co-locating these with that CR was a TRUE DEADLOCK: unknown kind -> pass aborts -> CR never
|
|
# applied -> CRD never created -> platform-config never converges -> every tier below it blocked. It was
|
|
# invisible on dev (CDI CRDs long present) and cost 12h on prod's cold start, 2026-09-05.
|
|
# They live here beside the KubeVirt/CDI component and are referenced in place from
|
|
# platform-config-cdi/kustomization.yaml (dependsOn: platform-config, revision-gated).
|
|
#
|
|
# `apps-vms` dependsOn platform-config-cdi for these: a DataVolume created before the longhorn-vm
|
|
# profile below exists is stamped RWO/Filesystem and is permanently not live-migratable.
|
|
#
|
|
# CDI AUTO-CREATES a StorageProfile per StorageClass and fills its STATUS (inferred capabilities).
|
|
# The operator owns `.status`; the USER owns `.spec`. Setting `.spec` here does NOT fight CDI — it
|
|
# overrides only the fields we set (server-side apply), and CDI keeps reconciling status around them.
|
|
#
|
|
# ── longhorn: turn on SNAPSHOT smart-clone ─────────────────────────────────────────────────────
|
|
# Default (empty spec) the longhorn profile reports `cloneStrategy: copy` — CDI clones a golden image
|
|
# by spinning a host-assisted byte-for-byte copy pod (slow, doubles I/O). With external-snapshotter
|
|
# installed and a driver.longhorn.io VolumeSnapshotClass present (../longhorn/volumesnapshotclass.yaml),
|
|
# `cloneStrategy: snapshot` makes CDI clone by taking a CSI VolumeSnapshot and provisioning the new
|
|
# PVC from it — near-instant, space-efficient. claimPropertySets left unset: CDI keeps inferring the
|
|
# class's native RWO/Filesystem, correct for ordinary (non-migratable) longhorn PVCs.
|
|
apiVersion: cdi.kubevirt.io/v1beta1
|
|
kind: StorageProfile
|
|
metadata:
|
|
name: longhorn
|
|
annotations:
|
|
homelab.keithjackson.dev/adr: ADR-0005
|
|
spec:
|
|
cloneStrategy: snapshot
|
|
---
|
|
# ── longhorn-vm: SNAPSHOT smart-clone + RWX/Block for live-migratable VM disks ──────────────────
|
|
# This is the default *virtualization* StorageClass (is-default-virt-class in ../longhorn/
|
|
# storageclasses.yaml). Its profile must advertise the access/volume mode combo Longhorn 1.7.3
|
|
# supports for migratable RWX — ReadWriteMany + Block — so every VM DataVolume CDI provisions on this
|
|
# class is stamped RWX/Block and is therefore live-migratable. Together with cloneStrategy: snapshot
|
|
# (smart clone) this profile is NON-DEGRADED (supports smart-clone AND RWX), which is what clears the
|
|
# CDIDefaultStorageClassDegraded alert (the default virt class must support BOTH).
|
|
apiVersion: cdi.kubevirt.io/v1beta1
|
|
kind: StorageProfile
|
|
metadata:
|
|
name: longhorn-vm
|
|
annotations:
|
|
homelab.keithjackson.dev/adr: ADR-0005
|
|
spec:
|
|
cloneStrategy: snapshot
|
|
claimPropertySets:
|
|
- accessModes:
|
|
- ReadWriteMany
|
|
volumeMode: Block
|