fix(chart): target device plugin monitor port by name - #2979
Conversation
The monitor service hardcodes targetPort to the numeric container port, unlike the scheduler's monitor service which targets by name to avoid drift if the container port ever changes. Apply the same pattern here, matching the metrics port name in daemonsetnvidia.yaml. Signed-off-by: Akanksha Trehun <akankshatrehun@gmail.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: magic-peach 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 |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe HAMi Helm chart adds a configurable monitor target port. The default is the named ChangesMonitor target port configuration
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to The monitor Service now targets the monitor container’s named metrics port, with a documented configurable default. Default deployments retain the same metrics endpoint behavior and no merge-blocking risk remains. 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 |
What type of PR is this?
/kind bug
What this PR does / why we need it:
The device plugin monitor Service hardcodes
targetPort: 9394instead of targeting the container port by name, unlike the scheduler's equivalent monitor Service (fixed in #2895) which targets by name to avoid drift if the container port number ever changes. This applies the same fix here: addsdevicePlugin.service.monitorTargetPort(defaultmetrics) tovalues.yaml, uses it inmonitorservice.yaml, and documents it in the chart README, mirroring #2895's pattern exactly.Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Confirmed via grep that this was the only remaining hardcoded
targetPortof this kind in the chart. Verified rendered output is functionally identical at default values (helm templatediff shows only the port field changing from the numeric literal to the equivalent name), andhelm lintpasses.Does this PR introduce a user-facing change?:
No behavior change at default values; adds a new
devicePlugin.service.monitorTargetPortvalue for consistency with the scheduler service.This PR was written primarily by Claude Code, an AI assistant, under my direction and review. I verified the change by comparing rendered chart output before and after, and reviewed the diff before submitting.
Summary by CodeRabbit
New Features
metricsport and can be customized through Helm values.Documentation