Loading
Fix print_pod_warning_events not suppressing pod scheduling warnings
What does this MR do?
print_pod_warning_events=false only gated the Kubernetes Event API
warnings retrieved after a job failed (logPodWarningEvents in
executors/kubernetes/kubernetes.go). It did not stop getPodPhase
in executors/kubernetes/util.go from unconditionally printing pod
condition messages (for example Unschedulable: "0/3 nodes are available...") while polling for the pod to become ready, so users
still saw scheduling warnings in job output regardless of the
setting.
This threads GetPrintPodWarningEvents() down into getPodPhase and
gates that condition-printing loop behind the same check. The general
"Waiting for pod..." progress line is left untouched since it isn't a
warning. Docs are updated to describe both surfaces the setting now
controls.
A separate, unrelated gap was also found: printPodEvents (gated
behind the opt-in FF_PRINT_POD_EVENTS feature flag, default off)
also doesn't check print_pod_warning_events. Nothing in the linked
issue indicates that flag was in play, so it isn't addressed here.
Why was this MR needed?
Closes #38982 (closed)
What's the best way to test this MR?
go test ./executors/kubernetes/... -run TestWaitForPodRunning -vTwo new cases cover the fix: one confirms the warning text still prints when the setting is enabled (default), the other confirms it is suppressed when disabled.