Summary
recipes/components/gpu-operator/values.yaml now pins driver.kernelModuleType: auto, replacing the deprecated no-op useOpenKernelModules: true (done in #2439). auto records today's effective behaviour. This issue is to decide whether it should instead be open.
Background
useOpenKernelModules was deprecated and made a no-op by the GPU Operator chart. The identical note appears in both v26.3.3 and v26.7.0 values.yaml:
NOTE: useOpenKernelModules has been deprecated and made no-op. Please use kernelModuleType instead.
So the key had stopped having any effect before #2439 touched it — AICR clusters have been running the chart default kernelModuleType: auto regardless of what that line said. #2439 replaced the dead key with an explicit auto, which is behaviour-preserving and needed no validation.
The open question
Per the ClusterPolicy CRD:
KernelModuleType represents the type of driver kernel modules to be used when installing the GPU driver. Accepted values are auto, proprietary and open. NOTE: If auto is chosen, it means that the recommended kernel module type is chosen based on the GPU devices on the host and the driver branch used.
The dead key expressed an intent — open kernel modules — that we are no longer stating. auto is a delegation, not a declaration.
Setting open would pin that intent back, but it is a real behaviour change on any hardware where auto currently selects proprietary. That needs hardware validation, which is why it was explicitly kept out of #2439 rather than riding a version bump.
What needs determining
- For each supported accelerator, what does
auto actually resolve to against the pinned driver branch (595.91.07)? Blackwell and Grace effectively require open modules, so auto almost certainly selects open there — but A100, L40S, H100 and RTX PRO 6000 on various host OSes need checking rather than assuming.
- Is there any supported family where
open would break or degrade? If not, pinning open is the stronger declaration and matches the house pattern of pinning intent explicitly rather than inheriting a chart default (cf. devicePlugin.enabled, driver.version).
- Does OCP need the same treatment?
recipes/components/gpu-operator-ocp/manifests/clusterpolicy.yaml renders kernelModuleType: {{ $v.driver.kernelModuleType | default "auto" }} and the OCP values file sets nothing, so OCP relies on the template fallback. If the base moves to open, OCP should be decided deliberately rather than diverging by omission.
Options
A. Keep auto (status quo after #2439). Zero risk, matches what has been running. But it delegates a decision the catalog used to state, and the resolved value can shift silently if NVIDIA changes auto's heuristic or we change the driver branch.
B. Pin open. Restores the original intent explicitly and makes the value stable across driver-branch changes. Requires validating every supported accelerator family first; a family where auto currently picks proprietary would change behaviour.
C. Pin per family. open where validated, auto elsewhere. Most precise, most surface — and note the placement rule from #2438 applies: a constraint-style value declared on a shared overlay is overwritten by a later one under last-wins, so per-family values need the same care.
Recommendation
Not urgent. auto is safe and is what has been running for at least one chart generation. Worth resolving alongside the next driver-branch bump, when the auto resolution is being re-checked on hardware anyway.
Related: #2439 (replaced the dead key), #2383 (pinned-version audit)
Summary
recipes/components/gpu-operator/values.yamlnow pinsdriver.kernelModuleType: auto, replacing the deprecated no-opuseOpenKernelModules: true(done in #2439).autorecords today's effective behaviour. This issue is to decide whether it should instead beopen.Background
useOpenKernelModuleswas deprecated and made a no-op by the GPU Operator chart. The identical note appears in both v26.3.3 and v26.7.0values.yaml:So the key had stopped having any effect before #2439 touched it — AICR clusters have been running the chart default
kernelModuleType: autoregardless of what that line said. #2439 replaced the dead key with an explicitauto, which is behaviour-preserving and needed no validation.The open question
Per the ClusterPolicy CRD:
The dead key expressed an intent — open kernel modules — that we are no longer stating.
autois a delegation, not a declaration.Setting
openwould pin that intent back, but it is a real behaviour change on any hardware whereautocurrently selects proprietary. That needs hardware validation, which is why it was explicitly kept out of #2439 rather than riding a version bump.What needs determining
autoactually resolve to against the pinned driver branch (595.91.07)? Blackwell and Grace effectively require open modules, soautoalmost certainly selects open there — but A100, L40S, H100 and RTX PRO 6000 on various host OSes need checking rather than assuming.openwould break or degrade? If not, pinningopenis the stronger declaration and matches the house pattern of pinning intent explicitly rather than inheriting a chart default (cf.devicePlugin.enabled,driver.version).recipes/components/gpu-operator-ocp/manifests/clusterpolicy.yamlrenderskernelModuleType: {{ $v.driver.kernelModuleType | default "auto" }}and the OCP values file sets nothing, so OCP relies on the template fallback. If the base moves toopen, OCP should be decided deliberately rather than diverging by omission.Options
A. Keep
auto(status quo after #2439). Zero risk, matches what has been running. But it delegates a decision the catalog used to state, and the resolved value can shift silently if NVIDIA changesauto's heuristic or we change the driver branch.B. Pin
open. Restores the original intent explicitly and makes the value stable across driver-branch changes. Requires validating every supported accelerator family first; a family whereautocurrently picks proprietary would change behaviour.C. Pin per family.
openwhere validated,autoelsewhere. Most precise, most surface — and note the placement rule from #2438 applies: a constraint-style value declared on a shared overlay is overwritten by a later one under last-wins, so per-family values need the same care.Recommendation
Not urgent.
autois safe and is what has been running for at least one chart generation. Worth resolving alongside the next driver-branch bump, when theautoresolution is being re-checked on hardware anyway.Related: #2439 (replaced the dead key), #2383 (pinned-version audit)