fix(scheduler): fail closed on invalid HAMi device requests instead of binding GPU-less pods (#2994)

fix(scheduler): fail closed on invalid HAMi device requests instead of binding GPU-less pods

An invalid HAMi device request (for example an mthreads core limit outside
0-100) was silently dropped by GenerateResourceRequests, so the pod looked
device-less, was bound to a node, and ran with no GPU at all.

Devices.GenerateResourceRequests now returns (request, error), so each
backend can distinguish an invalid request from no request.
All 16 backends return device.ErrInvalidDeviceRequest on invalid input.
Resourcereqs propagates the error; Filter rejects the pod with a
FilteringFailed event instead of returning all nodes.
The admission webhook returns the real error instead of a generic quota
message.
mthreads and iluvatar: the MutateAdmission count*cores total is divided
back to a per card value, and uneven totals are rejected.

Signed-off-by: Eshiv Pandey eshivpandey18@gmail.com

fix(device): address review feedback on invalid device request validation


enflame GCU and kunlun vdevice: reject device counts outside the int32
range before narrowing to int32, instead of silently wrapping.
mthreads: divide the admission-generated core total back to a per card
value whenever more than one device is requested, so totals at or below
100 (count*16 for two to six cards) are normalized too, and keep the per
card limit check after the division.

Signed-off-by: Eshiv Pandey eshivpandey18@gmail.com

test(cambricon): assert the error return in Test_GenerateResourceRequests

The error-path cases (zero/negative/overflowing counts, malformed memory)
only compared the empty request and discarded the returned error, so they
no longer proved the request is rejected. Capture the error and assert its
message, and require a nil error for the accepted cases.
Signed-off-by: Eshiv Pandey eshivpandey18@gmail.com

fix(device): treat an explicit zero device count as device-less, not invalid

The fail-closed change rejected any count <= 0, but zero is not a malformed
request: it is how a workload says it wants none of this vendor’s devices.
PR #2740 established that reading, returning an empty request so the pod is
admitted and scheduled without a device, and charts commonly render a
disabled GPU count as 0.
fitResourceQuota runs GenerateResourceRequests on every pod the webhook
sees, not only on pods carrying device resources, so an error for zero
turned ordinary CPU pods with “nvidia.com/gpu: 0” into admission denials.
Split the guard: zero returns an empty request with a nil error, while a
negative or overflowing count still fails closed. A backend for which zero
really is malformed keeps rejecting it in MutateAdmission, which only
rejects containers that actually carry its resources – awsneuron’s shared
validator is left untouched for exactly that reason.
Also rewrite the mthreads Coresreq comment. The divide is unconditional on
purpose and cannot adopt iluvatar’s “corenums > 100 && n > 1” gate: iluvatar
writes count100 so every multi-card total exceeds 100, while mthreads
writes count16, whose 2-to-6 card totals are 32 to 96. Gating on > 100
there would leave those totals undivided and report 16x too many cores per
card. A test pins the reasoning.
Signed-off-by: Eshiv Pandey eshivpandey18@gmail.com

fix(device): reject a device count that does not fit in an int64

Quantity.AsInt64 fails for a count that is integral but larger than an
int64, such as 1Ei or 1e19. The apiserver accepts those for an extended
resource, so they reach the backends, where the failed conversion fell
through to an empty request with a nil error. That is the silently
device-less pod this change set exists to remove, so report it as an
invalid request instead.
Assert both this and the zero-is-device-less contract across every
registered backend at once, since either is easy to regress one backend
at a time.
Signed-off-by: Eshiv Pandey eshivpandey18@gmail.com

fix(device-plugin): fail closed on config load error instead of Fatalf

LoadNvidiaDevicePluginConfig aborted the process with klog.Fatalf when
the device config file failed to load. After master’s strict-YAML config
parsing (#2941), that path became reachable from
TestLoadNvidiaDevicePluginConfigFailsWhenTheNodeCannotBeRead, which fed a
minimal config and expected a returned error; the Fatalf killed the whole
test binary instead.
Return the error like the node-read path already does, so a bad config
surfaces to the caller (factory.go already handles it) rather than taking
the plugin down.
Signed-off-by: Eshiv Pandey eshivpandey18@gmail.com

Signed-off-by: Eshiv Pandey eshivpandey18@gmail.com