fix(config): respect ConfigMap values when CLI flag is not explicitly set

[100milliongold]

Summary

LoadNvidiaConfig() (pkg/util/util.go) loads the device-plugin
ConfigMap (volcano-vgpu-device-config) into nvidiaConfig, and then
unconditionally overwrites DeviceSplitCount, DeviceCoreScaling,
and GPUMemoryFactor with the matching CLI flag values:

nvidiaConfig.DeviceSplitCount  = config.DeviceSplitCount
nvidiaConfig.DeviceCoreScaling = config.DeviceCoresScaling
nvidiaConfig.GPUMemoryFactor   = config.GPUMemoryFactor

Because each flag carries a per-flag default (--gpu-memory-factor=1,
--device-split-count=2, etc.), this silently discards whatever the
operator put in the ConfigMap, even when the flag is never passed on
the command line.

Symptom that surfaced this

On a node with 2 × 46 GiB GPUs, an operator sets
gpuMemoryFactor: 1024 in the ConfigMap so the device-plugin advertises
~88 vgpu-memory devices instead of ~92 K (so the kubelet ↔ plugin
ListAndWatch gRPC stays under the default 4 MiB receive limit). The
CLI default (1) silently overrode the ConfigMap, the plugin advertised
~92 K devices, kubelet dropped the advertise, and kubectl describe node reported:

Allocatable:
  volcano.sh/vgpu-cores:  "200"
  volcano.sh/vgpu-memory: "0"     # <- dropped
  volcano.sh/vgpu-number: "20"

The Volcano scheduler's capacity plugin then computes
realCapability = min(cluster_total, queue.capability) = 0 and rejects
every Pod with queue resource quota insufficient: insufficient volcano.sh/vgpu-memory — even when the queue capability is set
correctly.

The only way to make the ConfigMap-supplied value take effect today is
to also pass the same value via the DaemonSet args:, which makes the
ConfigMap field useless.

Fix

Gate the CLI-flag override on cli.Context.IsSet() so the flag wins
only when the user actually passed it on the command line.

if c.IsSet("device-split-count") {
    nvidiaConfig.DeviceSplitCount = config.DeviceSplitCount
}
if c.IsSet("device-cores-scaling") {
    nvidiaConfig.DeviceCoreScaling = config.DeviceCoresScaling
}
if c.IsSet("gpu-memory-factor") {
    nvidiaConfig.GPUMemoryFactor = config.GPUMemoryFactor
}

Compatibility

• No flags + no ConfigMap → values remain zero (unchanged).
• No flags + ConfigMap set → ConfigMap wins (was previously: flag default silently won).
• Flag explicitly passed → flag wins (unchanged).
• Flag explicitly passed + ConfigMap set → flag wins (unchanged, matches typical CLI-over-config precedence).

The only behavior change is the second case — and that is the case the
ConfigMap fields exist for, so it's the bug-fix direction.

Test plan

• go build ./pkg/util/... ✓
• Reproduced the original 0-allocatable symptom on RTX 6000 Ada × 2 with the upstream binary.
• Built the plugin from this branch, kept the --gpu-memory-factor flag out of the DaemonSet args, set gpuMemoryFactor: 1024 only in the ConfigMap → node Allocatable correctly reports volcano.sh/vgpu-memory: 88 and Pods with volcano.sh/vgpu-memory: 23 (chunks) schedule and run.

Related

The 4 MiB ListAndWatch limit and the gpuMemoryFactor mitigation are
documented in #118's README troubleshooting section. That PR is purely docs; this is the underlying behavior fix.

[DSFans2014]

/lgtm

[archlitchi]

/lgtm

[hami-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 100milliongold, archlitchi

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [archlitchi]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment