feat(dpf): report DPU conditions and agent status in the host snapshot - #5374
feat(dpf): report DPU conditions and agent status in the host snapshot#5374abvarshney-nv wants to merge 1 commit into
Conversation
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (5)
Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review. Summary by CodeRabbit
WalkthroughThe SDK host snapshot now includes DPU conditions, operational conditions, and agent status. New tests cover populated and absent status fields. The DPF documentation describes these fields and their ChangesDPU snapshot status
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This change adds DPU condition, operational-condition, and agent-status details to the host snapshot without changing existing fields or downstream behavior; no actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 18.75% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 32 functions across 4 files. (1 skipped: 1 unsupported.)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
🌿 Preview your docs: https://nvidia-preview-pull-request-5374.docs.buildwithfern.com/infra-controller |
`dpf snapshot` reported only `phase` and `bfbFile` from a DPU's status, so
it answered where provisioning had reached but never why it had stopped
there. DPF has since grown three status surfaces that carry the reason.
Adds them to `DpuSummary`, verbatim rather than flattened:
- `conditions`, whose reason and message explain the phase
- `operationalConditions`, the DPU's health once provisioned, which is a
separate axis from provisioning progress
- `agentStatus`, what the DPU-side agent reports about itself
Passing the CR types through unchanged keeps the payload lossless and
means a field DPF adds later shows up without another change here. The
keys inside each are therefore the CRD's own camelCase, not this
payload's snake_case.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
87be6dc to
1366aca
Compare
dpf snapshotreported onlyphaseandbfbFilefrom a DPU's status, so it answered where provisioning had reached but never why it had stopped there. DPF has since grown three status surfaces that carry the reason.This adds them to the snapshot payload, verbatim rather than flattened:
conditions— thereasonandmessageexplaining the phaseoperationalConditions— the DPU's health once provisioned, a separate axis from provisioning progressagentStatus— what the DPU-side agent reports about itselfPassing the CR types through unchanged keeps the payload lossless and means a field DPF adds later shows up without another change here. The trade is that keys inside these three are the CRD's own camelCase while the wrapper keys stay snake_case:
HostDpfSnapshotis documented as "not a stable wire format", and the only other consumer (machine-controller/src/dpf.rs) reads justdpu_nodeanddpu_devices, so nothing downstream is affected.Related issues
None filed.
Type of Change
Breaking Changes
Testing
Additional Notes
snapshot_hosthad no test coverage before this. Newcrates/dpf/src/test/sdk_host_snapshot.rscovers all three surfaces reported together, partial status not dragging absent fields into existence, and a DPU with no status at all.Unrelated and pre-existing on
main:cargo check -p carbide-api-corefails onmethod 'key' is never usedatcrates/api-core/src/api.rs:3706. Confirmed present without this change.