---
# 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