mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-04 11:07:03 +09:00
Aleksei Sviridkin
4a16c84832
Adds hack/check-gpu-operator-variants.bats. The test renders both
package variants with helm template and asserts the resulting
ClusterPolicy spec for the values that this PR cares about:
* ccManager.enabled=false (pinned in values.yaml; upstream v26 default
was flipped to true)
* vgpuDeviceManager.enabled=false (same — and on Ada+/Blackwell the
DaemonSet would crashloop because /sys/class/mdev_bus is empty)
* sandboxWorkloads.defaultWorkload — vm-passthrough on the default
variant, vm-vgpu on the vgpu variant; without these the upstream
'container' default makes either variant a silent no-op on
unlabelled GPU nodes
* vgpuManager.enabled=true on the vgpu variant; driver / devicePlugin
enabled=false on both variants (proprietary host driver path is
out of scope for both passthrough and SR-IOV vGPU)
Negative-tested locally: deleting any of these settings makes the
corresponding test fail, so it actually guards regressions on the
next chart bump.
Also addresses last-pass review comments:
* values-passthrough.yaml: set sandboxWorkloads.defaultWorkload=
vm-passthrough so the default variant is symmetric with the vgpu
variant — neither relies on per-node labels for the variant to
activate. Without this the upstream default 'container' would
apply on unlabelled GPU nodes and vfio-manager would never start.
* values.yaml: rewrite the vgpuDeviceManager comment to lead with
the load-bearing reason (mdev path missing on Ada+/Blackwell)
instead of the secondary 'stays at zero pods on passthrough'
rationalisation.
* docs/gpu-vgpu.md: add a 'Migrating from chart v25.x' subsection
in the Licensing section pointing at the configMapName ->
secretName rename. Old key still works upstream but emits a
deprecation warning; PR body release note already calls this out
but the docs were missing the migration breadcrumb.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
28 lines
1.5 KiB
YAML
28 lines
1.5 KiB
YAML
# Defaults applied to every variant of the gpu-operator package.
|
|
# The variant-specific files (values-passthrough.yaml, values-vgpu.yaml)
|
|
# layer on top.
|
|
gpu-operator:
|
|
# Upstream chart v26.x flips ccManager.enabled to true and
|
|
# ccManager.defaultMode to "on". On Hopper-class hardware
|
|
# (H100/H200/B100) with Confidential Computing capability this would
|
|
# auto-enable CC mode after a chart upgrade — a non-trivial behavior
|
|
# change. On non-CC-capable GPUs (L40S, A100, T4, …) the DaemonSet
|
|
# deploys, probes the hardware, and no-ops, but it still enters the
|
|
# cluster's resource graph. Pin to false so the default footprint
|
|
# stays as it was on v25.x; users who want CC enable it explicitly.
|
|
ccManager:
|
|
enabled: false
|
|
# Upstream v26.x also flips vgpuDeviceManager.enabled to true. The
|
|
# primary reason this is pinned back to false: the device manager
|
|
# walks /sys/class/mdev_bus/, which does not exist on Ada Lovelace
|
|
# (L4/L40/L40S, …) or Blackwell (B100, …) on the vGPU 17/20 driver
|
|
# branch — it errors with «no parent devices found». Keeping the
|
|
# default-on would crashloop the DaemonSet on any modern GPU.
|
|
# Secondary consideration: in passthrough mode the operator does not
|
|
# apply the nvidia.com/gpu.deploy.vgpu-device-manager=true label, so
|
|
# the DaemonSet would stay at zero pods, but it would still render
|
|
# into the cluster. The vgpu variant explicitly re-affirms this in
|
|
# values-vgpu.yaml.
|
|
vgpuDeviceManager:
|
|
enabled: false
|