Aleksei Sviridkin 46eb90a74d feat(gpu): define the shared GPU keys, settings and start contract ...

The controller, the admission webhooks, the tenant chart, the policies
and cozystack-api all have to agree on the same label, annotation,
finalizer, scheduling gate and quota keys and on the settings ConfigMap
the policies take as a parameter, so they are defined once here.

The VMI webhook only checks a start and records it: the attachments of
the held claims, and the gpus entries, because KubeVirt renders the
launcher pod's requests from a VMI spec that cannot change later.
Placement happens in the controller while the launcher pod waits at a
scheduling gate, so no admission call waits on the binder, and a set
that does not fit leaves the VM starting instead of refusing it into
KubeVirt's start backoff. The pin and the ungating are one pod update,
because the API server lets a pod's node affinity gain requirements only
while the pod being updated is still gated.

A usage record is owned by its claim through an ownerReference, so no
WorkloadMonitor and no reserved label have to guard it. The
template-claim mark carries no VMI name, since a VMI name can exceed a
label value.

Register and Setup exist as no-ops so the controller can be wired to
them before the webhooks and reconcilers land.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>

2026-10-23 03:40:47 +03:00

..

setup_test.go

feat(gpu): define the shared GPU keys, settings and start contract

2026-10-23 03:40:47 +03:00

setup.go

feat(gpu): define the shared GPU keys, settings and start contract

2026-10-23 03:40:47 +03:00