A gpus entry now names a raw resource, a held GPUClaim or a
claimTemplate that orders a claim for as long as the VM runs. The
chart renders references only as the claim-reference label and the
claims annotation on the VMI template; the GPU webhook resolves them
at VMI creation and writes the gpus entries itself, so a list holds
raw names or references, never both.
Where gpu-operator does not serve GPUs to VMs no webhook would resolve
a reference and the VM would boot without its GPUs, so the platform
publishes the switch in _cluster and the chart refuses references
without it.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
With gpu.enabled the chart passes the GPU flags, serves the three GPU
admission webhooks with a cert-manager certificate, and exposes the
controller's metrics over HTTPS, where each scrape is authorised
through the token and access reviews the controller is granted.
The webhooks fail closed, so the controller runs two replicas spread
over nodes, under a disruption budget, and a replica is ready only
once the caches the webhooks read have synced. The pod webhook selects
virt-launcher pods with claim references and leaves migration targets
out, which KubeVirt deletes when they stay pending.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
The VMI webhook resolves a VMI's claim references, refuses what needs
no placement to judge, records the attachment of each held claim and
writes one gpus entry per unit with the class's resource name. It
binds, moves and creates nothing: budgets, capacity and template
claims are the controller's, so a VM whose set does not fit yet waits
at start instead of being refused into KubeVirt's backoff.
The pod webhook holds the launcher pod, and the temporary pod for
WaitForFirstConsumer volumes, at the claims' scheduling gate and adds
the tolerations of the claims' classes, which binding already counted
on. A repeated call adds neither twice, since a duplicate gate fails
pod validation. Migration targets are left alone, because KubeVirt
deletes a target pod that stays pending.
The order webhook refuses a tenant's GPUClaim that cannot be met now:
class, maxCount, published free units, budgets and the vGPU
entitlement. Template claims skip it; the tamper policy keeps their
mark out of tenants' hands.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
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>
Aleksei Sviridkin