chore: improve error handling in scheduler routes and device plugin - #2279
chore: improve error handling in scheduler routes and device plugin#2279shinigami-777 wants to merge 3 commits into
Conversation
Signed-off-by: shinigami-777 <chattopadhyaytamaghna@gmail.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: shinigami-777 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Welcome @shinigami-777! It looks like this is your first PR to Project-HAMi/HAMi 🎉 |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe change adds error handling for MIG parsing, vGPU filesystem setup, and scheduler HTTP response writes. Allocation tests now isolate the host hook path. ChangesDevice plugin error handling
Scheduler response error handling
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@pkg/device-plugin/nvidiadevice/nvinternal/plugin/server.go`:
- Around line 315-317: Update the MIG handling around yaml.Unmarshal to parse
into a zero-valued local nvidia.MigPartedSpec, and only assign it to
plugin.migCurrent after unmarshalling succeeds. On failure, reject the
configuration so writeMigConfig and any later plugin.ApplyMigTemplate call
cannot use stale or invalid MIG state.
- Around line 680-688: Update the directory creation and permission handling in
the Allocate flow around cacheFileHostDirectory and /tmp/vgpulock to remove the
world-writable 0777 defaults and the unconditional os.Chmod reset. Use
least-privilege directory modes with explicit ownership/group access, and
preserve isolation for pod-specific cache data and lock files while retaining
the existing failure handling.
- Around line 680-688: Check the return value of each os.Chmod call for
cacheFileHostDirectory and /tmp/vgpulock in the Allocate flow. On failure, call
PodAllocationFailed with the same allocation context and return an Allocate
error before mounts are appended, matching the existing MkdirAll failure
handling.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 004e9d20-18e8-4aaf-8729-809d4d139e8f
📒 Files selected for processing (2)
pkg/device-plugin/nvidiadevice/nvinternal/plugin/server.gopkg/scheduler/routes/route.go
mesutoezdil
left a comment
There was a problem hiding this comment.
the mkdir part changes behavior (silent -> abort) so pls put that in the release note field instead of "no".
| outStr := stdout.Bytes() | ||
| yaml.Unmarshal(outStr, &plugin.migCurrent) | ||
| if err := yaml.Unmarshal(outStr, &plugin.migCurrent); err != nil { | ||
| klog.Errorf("failed to unmarshal mig config: %v", err) |
There was a problem hiding this comment.
logging alone is not enough, migCurrent stays zero and the next lines still run w/ it, pls fall back to non mig like the sibling branch above
There was a problem hiding this comment.
Yes, made it similar to the sibling branch above it.
Signed-off-by: shinigami-777 <chattopadhyaytamaghna@gmail.com>
|
The test for pkg/device-plugin/nvidiadevice/nvinternal/plugin was failing earlier as expected due to the strict error handling for filesystem operations during pod allocation. When the plugin fails to clean up or set permissions on the cache directory or the lock directory, it aborts the allocation and returns an error. |
Signed-off-by: shinigami-777 <chattopadhyaytamaghna@gmail.com>
|
/assign @mesutoezdil |
|
Thanks for auditing these error paths. The PR bundles three unrelated changes—HTTP write logging, MIG YAML fallback behavior, and allocation-directory failure handling—without a shared reproducible defect. The added test setup does not exercise the newly changed failure paths, and the normal exact-head CI suite has not produced reviewable results. A broad mechanical error-handling sweep is difficult to validate and maintain, so we are closing this PR. Please submit any real failure as a separate, minimal change with a reproduction and a regression test for that exact path. |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
While investigating the codebase, I ran
errcheckmanually and noticed some unhandled errors that could lead to silent failures. These slipped through CI becauseerrcheckis disabled in the project's.golangci.yamlconfiguration. Furthermore, the entirepkg/device-plugindirectory is excluded from linter checks.This PR adds proper error checking and logging to prevent silent failures in these components.
Changes Made
pkg/scheduler/routes/route.go:Added error handling for HTTP
w.Write()calls. If writing the JSON response to the client fails (e.g., due to a dropped connection), it will now properly log aklog.ErrorSinstead of failing silently.pkg/device-plugin/nvidiadevice/nvinternal/plugin/server.go:yaml.Unmarshal. If unmarshaling fails, the plugin now logs an error, explicitly aborts the rest of the MIG setup block, and falls back to a non-MIG configuration. This prevents the plugin from silently continuing with an invalid, zero-value migCurrent configuration.os.MkdirAll,os.RemoveAll, andos.Chmod.Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Yes. By adding explicit error handling, the behavior of the device plugin has shifted from "silently ignoring" these errors to "explicitly aborting" the pod's resource allocation. This makes the plugin much safer and more predictable (since it no longer allows pods to start in an incomplete or incorrectly permissioned state).
AI assistance disclosure:
I manually ran
errcheckto catch the unhandled cases. The changes was made using assistance from Gemini 3.1 Pro. I understand and take responsibility for the implementation and have manually verified and tested it usingmake verifyandmake testbefore creating this PR.Summary by CodeRabbit
Summary by CodeRabbit