CAPVCO v0.5.0 — GPUs by type, and SR-IOV networking per pod
Two features, both validated end to end against a real whitesky.cloud backend.
GPUs (#34). A machine pool asks for a GPU by TYPE, not by instance:
gpu:
type: "NVIDIA A100"
count: 1
driverVersion: "550" # empty for a pre-baked image
The provider resolves that type against the location's per-card profiles,
reserves and attaches in a single call, records every reservation the moment it
exists, and releases them all on teardown. A vGPU is billed from the moment it
is reserved — detaching one does not stop the charge — so ownership is encoded
in the reservation name and cluster teardown reclaims every reservation it owns,
attached or not, including those left behind by a machine deleted with --force.
`capvco-gpucheck -orphans` reports anything that still escapes.
SR-IOV networking (#27). Pods get a NIC on an external network on demand, at CNI
time, instead of pre-attaching scarce virtual functions to every node. A
DaemonSet agent holds the credential and serialises attaches per VM; a host-side
CNI plugin moves the interface into the pod's namespace and configures the
address the platform assigned, leaving the default route with the primary CNI.
NICs are reclaimed when a pod goes, including pods that died without a CNI DEL.
The agent's credential is supplied by the operator and never defaulted to the
cluster credential.
Also in this release: first-boot package installs are retried and fail loudly
rather than producing a node that never joins; the feature-matrix e2e runs one
job per scenario, individually retryable; and the e2e now tests the branch's own
in-workload images rather than master's.
Not yet covered: a pod actually consuming a GPU (driver, device plugin,
nvidia-smi) needs GPU hardware this platform does not offer — see #34 and #37.
Upgrade notes: none. Both features are opt-in — GPUs via spec.gpu on a machine
template, SR-IOV via the add-on label plus spec.sriov.credentialSecretRef.
Full detail in !12; limitations in docs/known-limitations.md.