[Bug]: a partially specified NVIDIADriver startupProbe renders zeros instead of operator defaults

未关闭
  • 哪里不对？
#3,132 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@blacksoxx 已经在做这个了。

开始于 2026年10月28日。

  • #3133 来自 @blacksoxx —— 未关闭

评估

难度
3/5
预计耗时
1-2 天
新手友好度
67/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
go, kubernetes
领域
backend, devops

调研方向

Start in internal/state/driver.go at getDriverSpec and compare its startup probe handling with setContainerProbe in controllers/object_controls.go. Run the internal/state unit tests and inspect the rendered DaemonSet in manifests/state-driver/0500_daemonset.yaml. Done means a partially specified probe preserves user-set values and uses operator defaults for the remaining fields.

由索引模型根据 Issue 内容生成。

描述

Describe the bug

When an NVIDIADriver CR sets spec.startupProbe but leaves some fields unset, the GPU Operator renders explicit zeros for those fields into the driver DaemonSet, so the driver startup window collapses to the generic Kubernetes probe defaults instead of the operator's intended values.

getDriverSpec (internal/state/driver.go) applies getDefaultStartupProbe only when spec.StartupProbe == nil:

if spec.StartupProbe == nil {
    spec.StartupProbe = getDefaultStartupProbe(spec)
}

If the CR specifies the probe partially (for example startupProbe: {initialDelaySeconds: 120}), the unset fields stay zero, and manifests/state-driver/0500_daemonset.yaml renders failureThreshold: 0, periodSeconds: 0, timeoutSeconds: 0, successThreshold: 0. The API server then substitutes the generic defaults (failureThreshold 3, periodSeconds 10, timeoutSeconds 1) rather than the operator defaults (failureThreshold 120, timeoutSeconds 60). A driver that compiles for more than ~30s, or whose nvidia-smi probe takes longer than 1s, is then killed and restarted in a loop.

The ClusterPolicy path does not have this problem: setContainerProbe (controllers/object_controls.go) overlays only the non-zero user fields on top of the defaults. The two paths disagree.

To Reproduce

Apply an NVIDIADriver CR whose spec.startupProbe sets only initialDelaySeconds (any single field), and inspect the rendered driver DaemonSet: the other probe fields are 0.

Reproduced with a unit test over getDriverSpec: a CR with StartupProbe{InitialDelaySeconds: 120} yields failureThreshold 0 / periodSeconds 0 / timeoutSeconds 0 / successThreshold 0 instead of the operator defaults.

Expected behavior

A partially specified startupProbe keeps the fields the user set and falls back to the operator defaults for the rest, as the ClusterPolicy path already does.

Environment (please provide the following information):

  • GPU Operator Version: present in v26.7.2 and on main (internal/state/driver.go has no overlay for a partial probe); reproduced on main
  • OS: N/A for the reproduction (unit test, macOS arm64, Go 1.26)
  • Kernel Version: N/A (not run on a cluster)
  • Container Runtime Version: N/A (not run on a cluster)
  • Kubernetes Distro and Version: N/A (not run on a cluster; reproduced with the internal/state unit tests)

A fix is in the linked PR.

主要语言
Go
星标
2.9k
派生
587
平均合并
1 天 22 小时
30 天内合并 PR
63

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

NVIDIA/gpu-operator 的其他 Issue

查看 NVIDIA/gpu-operator 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。