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 admission webhooks and the option sources need the same readings
the controller makes: the permittedHostDevices table KubeVirt checks
GPU entries against and the table's GPU names, a tenant's declared
resourceQuotas, and the units a VMI's attached claims cover for
budgets. They move into the model unchanged, and the controller reads
them from there, so each has one copy.
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
The binder is the only writer of a claim's placement, so budget and
capacity checks that admission already ran cannot be raced past by two
replicas. Every event collapses into one pass over all GPU objects,
which serializes the decisions without per-object locks, and claims
are read past the cache so a unit booked in the last pass is never
booked again from a stale view.
A VM starts through its launcher pod, which the pod webhook holds at a
scheduling gate. The pass creates the VMI's template claims, gathers
the whole set onto one node that every class of the set tolerates and
has room on, then pins the pod there and removes the gate in one
update, since the API server lets a pod's node affinity change only
while the pod is gated. A set that cannot be placed keeps its pod
gated with a condition on its claims and a Warning event on the VMI,
once per change of reason, so the VM waits for capacity instead of
being refused into KubeVirt's backoff. The set goes only to a node the
pod's own node selector and required affinity accept and, when the VMI
has a volume bound to a node's PersistentVolume, that volume reaches.
Gated pods go before moves and new orders.
A pin cannot be undone, so a pinned pod its node refuses for lack of
resources is deleted and the node is skipped for that set for ten
minutes, or until its allocatable, taints or readiness change. The
template claims of the set go with its failed VMI, so the controller
also keeps the rejection in memory for the VM's next VMI. Only a VMI
whose pod is already pinned is deleted to free a claim whose node
cannot keep it; a VMI whose pod is gated has its set gathered instead.
The full pass also moves held sets off nodes that cannot keep them,
rebinds Lost sets before new orders, and binds new orders onto the
fullest node with room. Finalizers and usage records run with the
feature disabled too, so turning GPU off never hangs a namespace or
class deletion. Each usage record is owned by its claim and sits under
no WorkloadMonitor, so no tenant label can add or drop one, and
garbage collection removes it with the claim. Without a monitor label
the Workload controller would take such a record for an orphan, so it
now leaves a record owned by a GPUClaim to that owner.
The claims one VM names move, go Lost and are rebound as a set. Every
pass restores that invariant before it places anything, gathering a
set left partly Lost, by a write that failed half way or by a VMI that
ended next to held members, onto one node or sending all of it to
Lost, so each later step only ever changes whole sets.
A Lost claim already counts against its tenant's budgets, so the pod
of its still running VMI is not counted again under a raw GPU key; for
node capacity it is, since the claim itself holds no units. A pod is a
VMI's launcher only when the VMI lists it in status.activePods,
because whoever creates a pod sets its owner reference. The KubeVirt
watches start once KubeVirt serves its kinds, whose CRDs a fresh
install adds after this controller starts.
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