fix(inference): accept ip neighbor output that omits the filtered dev - #8527
Conversation
The DGX Spark managed-cluster connectivity probe runs `ip -j neigh show to <peer> dev <netdev>`. iproute2 applies `dev` as a server-side filter and then omits the `dev` key from the JSON it prints, so comparing the parsed `dev` against the requested netdev compared an empty string against the netdev and rejected every rail. A healthy two-rail direct CX-7 fabric could never qualify, and the managed vLLM onboard aborted at provider configuration on every dual DGX Spark. An absent `dev` already means the entry belongs to the requested netdev, which is what the sibling probe in vllm-station-cluster.ts assumes. The unit fixture hid the defect by emitting a `dev` key that real `ip` never returns for this query, so the fixture now mirrors the real output. Report which rail and which probe rejected the fabric instead of naming all three probes at once. A single line that fires when route, jumbo, and neighbor all pass independently leaves no way to act on the failure. Closes #8519 Signed-off-by: Dongni Yang <dongniy@nvidia.com>
The failure message called the probes "direct route" and "jumbo frame". The documentation and the DGX Station preparation guide call the same three probes route, neighbor, and jumbo-frame checks, so use those names in the message. Refs #8519 Signed-off-by: Dongni Yang <dongniy@nvidia.com>
|
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 (3)
📝 WalkthroughWalkthroughManaged-cluster connectivity probing now returns structured failure details. Route, jumbo, neighbor, and rail-validation failures identify the failed check, with network devices included where applicable. Neighbor validation accepts JSON without a ChangesConnectivity diagnostics
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant ManagedClusterDiscovery
participant probeConnectivity
participant connectivityCheck
ManagedClusterDiscovery->>probeConnectivity: connectivity requests
probeConnectivity->>connectivityCheck: validate each rail
connectivityCheck-->>probeConnectivity: failure details or null
probeConnectivity-->>ManagedClusterDiscovery: first failure or null
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Code Coverage OverviewLanguages: TypeScript TypeScript / code-coverage/pluginThe overall coverage in commit 028bb62 in the TypeScript / code-coverage/cliThe overall coverage in commit 028bb62 in the Show a code coverage summary of the most impacted files.
Updated |
PR Review Advisor — No blocking findings reportedAdvisor assessment: No blocking advisor findings reported Model lanes
Second-opinion terminology and E2E selections are advisory. Live E2E does not run automatically for pull requests. 2 semantic terminology decisionsTerminology decisions are advisory. They affect the assessment only when a separate finding identifies concrete semantic impact.
E2E guidanceAdvisory only. A maintainer can dispatch the default E2E suite against this exact revision. Recommended E2E: 1 optional E2E recommendation
This automated review informs maintainers. Warnings and suggestions do not require a response. A maintainer decides whether to merge. |
|
CI failure classification: confirmed transient runner-pressure timeout; failed jobs are being rerun. The failed shard timed out at Local validation on this branch completed the timed-out test together with the changed managed-cluster suite: 33/33 tests passed in 1.88 seconds after the normal CLI build. This supports an infrastructure/test-scheduling classification rather than a code defect in this PR. I am rerunning only the failed CI jobs. The separate Nemotron advisor service failure is optional and does not replace the successful primary review advisor. |
apurvvkumaria
left a comment
There was a problem hiding this comment.
Approved after an independent maintainer review of revision 028bb6250.
Security verdict: PASS. No blocking findings were identified.
| Category | Result | Evidence |
|---|---|---|
| Secrets and credentials | PASS | The three-file diff adds no credential material or secret handling. |
| Input validation | PASS | The filtered neighbor result can omit dev; an explicit different device, destination, MAC address, state, malformed JSON, or missing row still fails. Route and rail inputs retain their existing validation. |
| Authentication and authorization | PASS | The change does not alter SSH trust, identity checks, authorization, or credential custody. |
| Dependencies | PASS | The change adds no dependency or package update. |
| Error handling and logging | PASS | Structured failures expose only the check, host, and network device required for diagnosis. They do not expose credentials or internal paths. |
| Cryptography and data protection | PASS | Not applicable. The change adds no cryptographic operation or data-storage path. |
| Configuration and secure defaults | PASS | The two-rail requirement, direct-route requirement, jumbo-frame probe, expected peer MAC check, and accepted neighbor-state allowlist remain fail-closed. |
| Security testing | PASS | The regression test covers real ip JSON without dev; targeted tests also cover route, jumbo-frame, neighbor, and rail-cardinality failures. |
| Holistic posture | PASS | The branch accepts only the field omission caused by the command's own device filter and does not weaken host, rail, SSH, route, MAC, or neighbor-state qualification. |
Correctness review also confirmed deterministic first-failure reporting in the existing node and rail order, two distinct validated rail devices, and documentation-aligned route, neighbor, and jumbo-frame messages.
Documentation writer review: PASS, no documentation change needed. The two-DGX Spark page already documents the healthy topology and the route, neighbor, and jumbo-frame requirements; no page quotes the replaced aggregate error. The receipt matches this revision and the current AGENTS.md content.
Verification: the focused managed-cluster suite passed 30/30 tests, CLI type-checking passed, CodeRabbit reported no actionable comments, the primary PR Review Advisor reported no findings, all review threads are resolved, both commits are GitHub-verified and carry DCO trailers, and the DCO check passes. The focused CI rerun for the unrelated runner-pressure timeout remains subject to the normal required checks; this approval does not waive any check.
…e check (#8692) <!-- markdownlint-disable MD041 --> ## Summary The dual DGX Spark managed-vLLM onboard aborted at "[3/8] Configuring inference provider" (`The route check failed …`, exit 1) on verifiably healthy clusters. The connectivity route check ran `ip -j route get <peer> from <src> oif <dev>` and matched the source against `route.prefsrc ?? route.src`; on iproute2 6.1.0 (DGX OS 7.5.0) the `from <src>` argument makes iproute2 echo the source back as the JSON `from` field instead of `prefsrc`/`src`, so the source was `undefined` and every healthy rail failed the check. This reads the source from `from` as well, matching the sibling Python probe and the neighbor-check field-shape fix in #8519/#8527. ## Related Issue Closes #8684 ## Changes - `src/lib/inference/serving/managed-cluster-discovery-production.ts`: in `connectivityCheck`, read the route source as `route.prefsrc ?? route.src ?? route.from` so the check accepts the source when iproute2 6.1.0 echoes it as `from`. One-field widening; no behavior change for outputs that carry `prefsrc`/`src`. - `src/lib/inference/serving/managed-cluster-discovery.test.ts`: the two connectivity route mocks emitted an unrealistic `{ prefsrc, scope: "link" }` shape (with a `from` invocation) that hid the defect; update them to the real iproute2 6.1.0 shape (`{ dst, from, dev, flags, uid, cache }` — source as `from`, no `prefsrc`/`scope`), and add a `#8684` regression asserting a healthy dual-Spark cluster passes. With the mocks corrected, the existing healthy-path tests fail without the source fix. ## Type of Change - [x] Code change (feature, bug fix, or refactor) - [ ] Code change with doc updates - [ ] Doc only (prose changes, no code sample modifications) - [ ] Doc only (includes code sample changes) ## Quality Gates - [x] Tests added or updated for changed behavior - [ ] Existing tests cover changed behavior — justification: - [ ] Tests not applicable — justification: - [ ] Docs updated for user-facing behavior changes - [x] Docs not applicable — justification: internal connectivity-probe parsing fix; it restores the already-documented dual DGX Spark managed-vLLM onboard to work as documented, with no new command, flag, option, or documented contract. - [x] Sensitive paths changed (security, policy, credentials, preflight, onboarding, inference, runner, sandbox, or messaging) - [ ] Sensitive-path review completed or maintainer-approved waiver recorded — reviewer/approval link/justification: `inference`/onboarding connectivity path. The change only widens the accepted iproute2 source field (`?? route.from`) to fix a false-negative route check; it does not weaken any check (dev/gateway/scope/source-match all still enforced) or touch credentials/policy. Same accepted field-shape class as #8519/#8527. Deferred to normal CODEOWNERS review. - [ ] Non-success, skipped, or missing CI check accepted by maintainer — check name, approval link, and follow-up issue: ## Documentation Writer Review - [x] Documentation writer subagent reviewed the completed changes - Result: `no-docs-needed` - Evidence: No documentation paths changed. The fix is an internal iproute2-output parsing correction in the managed-cluster connectivity probe; it makes the documented dual DGX Spark managed-vLLM onboard succeed on healthy clusters rather than changing any documented behavior, command, flag, or output. - Agent: Claude Code <!-- docs-review-head-sha: bcd7d2e --> <!-- docs-review-agents-blob-sha: c4923a3 --> ## Verification - [x] PR description includes a `Signed-off-by:` line and every commit appears as `Verified` in GitHub - [x] Normal `pre-commit`, `commit-msg`, and `pre-push` hooks passed, or `npm run validate:pr` passed after refreshing `origin/main` when hooks were skipped or unavailable - [x] Targeted behavior tests pass for the current change set, or tests are marked not applicable above — command/result or justification: `npx vitest run --project cli src/lib/inference/serving/managed-cluster-discovery.test.ts` on a fresh clone on an Ubuntu host (Node v22.23.1, `npm ci` + plugin build) → 31 passed. Two-way check: reverting only `managed-cluster-discovery-production.ts` to `origin/main` (keeping the corrected tests) fails 4 healthy-cluster tests incl. the new #8684 regression (route source `undefined` = bug reproduced with the real iproute2 6.1.0 output shape the reporter captured). - [ ] Applicable broad gate passed — `npm test` for broad runtime/test-harness changes; `npm run check` for repo-wide validation/coverage changes — command/result: - [x] Quality Gates section completed with required justifications or waivers - [x] No secrets, API keys, or credentials committed - [ ] `npm run docs` builds without warnings (doc changes only) - [ ] Doc pages follow the [style guide](https://github.com/NVIDIA/NemoClaw/blob/main/docs/CONTRIBUTING.md) (doc changes only) - [ ] New doc pages include SPDX header and frontmatter (new pages only) --- Signed-off-by: Jason Ma <jama@nvidia.com> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved route connectivity validation for environments using newer iproute2 output. * Connectivity checks now correctly recognize source addresses reported through the `from` field. * Prevented healthy dual-rail connections from being incorrectly flagged as unavailable. * **Tests** * Added coverage for connectivity responses matching iproute2 6.1.0 output. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Signed-off-by: Jason Ma <jama@nvidia.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Summary
The DGX Spark managed-cluster connectivity probe runs
ip -j neigh show to <peer> dev <netdev>.ipappliesdevas a server-side filter and then omits thedevkey from the JSON it prints, so comparing the parseddevagainst the requested netdev compared an empty string against the netdev and rejected every rail. A healthy two-rail direct ConnectX-7 fabric could never qualify, and the managed vLLM onboard aborted at[3/8] Configuring inference provideron every dual DGX Spark. The probe now treats an absentdevas belonging to the requested netdev, and the failure message names the rail and the probe that rejected the fabric instead of naming all three probes at once.Related Issue
Closes #8519
Changes
connectivityCheckaccepts a neighbor entry whosedevkey is absent, becauseipalready filtered ondev. This matches the assumption the sibling probe insrc/lib/inference/vllm-station-cluster.tshas always made.probeConnectivityreturnsManagedClusterConnectivityFailure | nullinstead ofboolean, so the caller can report which rail and which probe failed.nullmeans every rail passed every probe.probeManagedClusterManagedServingCapabilityrenders that failure. Before:Direct route, neighbor, or jumbo connectivity failed on {hostname}.After:The neighbor check failed on {hostname} rail {netdev}., orManaged cluster connectivity needs exactly two direct ConnectX-7 rails on {hostname}.when the candidate rail set is unusable and no per-rail probe ran.devkey that realipnever returns for this query, which is why unit tests passed while every real fabric was rejected. The fixture now mirrors the real output, and that change alone turns the existing test red onmain.ManagedClusterConnectivityFailureis not a compatibility or extension layer. Its current consumer is the failure message inprobeManagedClusterManagedServingCapability, which cannot name the failing rail or probe while the probe returns a bareboolean.names the rail and the sub-check that rejected the fabric (#8519)protects that contract.Type of Change
Quality Gates
docs/inference/set-up-vllm-on-two-dgx-sparks.mdxdocuments the healthy topology as a prerequisite, which is the topology this defect rejected, so the prose was already correct.Documentation Writer Review
no-docs-neededdocs/inference/set-up-vllm-on-two-dgx-sparks.mdx,docs/inference/set-up-vllm-on-two-dgx-stations.mdx, anddocs/get-started/dgx-station-preparation.mdx. No page quotes the previous message, and the generic "route, neighbor, and jumbo-frame checks" phrasing stays accurate. The review changed the message to use those documented check names.Verification
Signed-off-by:line and every commit appears asVerifiedin GitHubpre-commit,commit-msg, andpre-pushhooks passed, ornpm run validate:prpassed after refreshingorigin/mainwhen hooks were skipped or unavailablenpx vitest run --project cli src/lib/inference/serving/managed-cluster-discovery.test.ts— 30 passed. Both new tests fail on the unfixed source (expected false to be null,expected false to deeply equal { check: 'jumbo' }) and pass after the fix.npm run typecheck:cliclean.npm testfor broad runtime/test-harness changes;npm run checkfor repo-wide validation/coverage changes — command/result:npm run docsbuilds without warnings (doc changes only)Notes for reviewers
I do not have two DGX Spark systems, so this is verified at the unit layer rather than on the wire. The
ipbehavior itself is reproducible on any Linux host:That is iproute2 5.5, and the report is iproute2 6.1, so the defect is not specific to one iproute2 release.
src/lib/inference/serving/managed-cluster-discovery.tshas a pre-existingassist/source/organizeImportsfinding at its import block that also reports on unmodifiedmain. I left it alone rather than widen this diff.npx vitest run --project cli src/lib/inference/reports 3 failures insrc/lib/inference/vllm-station-model-staging.test.ts. Those reproduce identically with this change stashed, so they are pre-existing and unrelated.Reporter #8519 also filed #8520 against the same install path. This change does not address that one.
Signed-off-by: Dongni Yang dongniy@nvidia.com
Summary by CodeRabbit