Conversation
adbefea to
bc571ff
Compare
|
Thanks for pulling these together, and for the hardening on top — several of the One request on attribution. The body credits #1389–#1395, which I appreciate, #1389, #1390 and #1394 came from a different contributor (@100-JM) — their Happy to close #1391, #1392 and #1395 once this lands. #1393 stays open as you |
|
Following up on the attribution point above for #1389, #1390 and #1394, which this PR incorporates (the I appreciate the extra hardening — the I'll close #1389, #1390 and #1394 once this lands. #1397 (running the remaining |
|
@dholt Squashing the hard work and original code of multiple contributors (@100milliongold and @100-JM from PRs #1389 through #1395) into a single commit under one author's name goes against the fundamental principles of open-source collaboration. While the additional hardening work is appreciated, stripping the original authors of their proper credit in the git history and contributor graph is simply unacceptable. Please respect your fellow contributors and amend this commit to include the requested Co-authored-by trailers before merging. Proper attribution is a core pillar of the open-source community. |
Resolve the release-blocking SSH guard, peer-memory, DCGM, exporter, and Pyxis contracts while preserving standalone component behavior and fail-closed validation. Co-authored-by: 100milliongold <je.kim@xiilab.com> Co-authored-by: 백지명 <wlaud9805@gmail.com>
Adapt the second-convergence diagnosis and approach proposed in #1397. Co-authored-by: 백지명 <wlaud9805@gmail.com>
d1f9622 to
4cd3944
Compare
|
@100milliongold @100-JM, I'm sorry your contributions were incorporated here without proper commit attribution. I've corrected the commits to credit your work, including the follow-up from #1397. Thank you for contributing these fixes and for calling this out. This PR is on hold; further integration of your PRs will preserve your original commits and authorship rather than squash them, and both of you will be acknowledged in the next release notes. |
Address the review on running GPU tasks outside the login device guard. The MIG probe was the only part of the MIG path that escaped the cgroup. `nvidia-mig-parted apply` and `assert` drive the very same GPUs, so once the repaired probe succeeds they still ran in the restricted ssh context and failed there. They now run in a transient unit as well, and the play runs privileged, which the standalone `nvidia-mig-parted` invocations needed anyway. `nvidia-driver.yml`'s `test nvidia-smi` gets the same treatment: that was the remaining driver check, and NVIDIA#1396 closed without landing it. The probe could not tell a GPU that does not support MIG from a query that never ran. Both end up with a non-zero status, and with the query piped into the match, `pipefail` reports the match's status in either case, so an operational failure -- a driver that does not answer, a transient service that could not start -- was silently read as "no MIG here" and the node was reported as converged without ever being looked at. The query is now kept apart from the match so its own status survives: 0 a GPU reports a MIG mode -> configure the node 1 queried fine, no MIG support -> skip the node 2 the query itself failed -> fail, with the reason Exit 2 is only fatal on a node where lspci actually found NVIDIA GPUs, so a node with no NVIDIA hardware still passes through untouched. Two smaller corrections from the same reading: the match accepts only a real MIG mode, since `grep -v N/A` also matched warnings nvidia-smi prints next to the values; and the Red Hat install branch now requires a successful capability probe, which the Debian branch already did. scripts/validation/tests/test_gpu_task_contracts.py covers this. The probe is executed as written against a mocked nvidia-smi and systemd-run, for a failed query (reported on stdout, on stderr, and not at all), an unsupported device, a noisy but successful query, and a repeated run with the device guard already active. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UiFVTVAyEMmn68Xvo9LSTf Signed-off-by: 백지명 <wlaud9805@gmail.com>
…e the login GPU guard
With slurm_login_on_compute enabled, login-compute-setup restricts the ssh
service's cgroup to /dev/nvidiactl so interactive users cannot reach GPUs
outside a Slurm job. Ansible arrives over the same ssh service, so every
task that runs nvidia-smi afterwards is restricted too (the filter is
per-cgroup, become does not help):
nvidia-smi -> rc=6, "No devices were found"
nvidia-smi -acp UNRESTRICTED -> rc=6
nvidia-smi --query-gpu=mig.mode -> rc=0 with "No devices were found"
That breaks the second run slurm-single-node.md asks for ("reboot manually
when prompted and then run Ansible again"): gpu-clocks.yml and the
nvidia-cuda.yml driver test fail, and nvidia-mig.yml treats the
"No devices" text as a MIG-capable GPU because it only filtered 'N/A'.
Run those nvidia-smi invocations through
`systemd-run --wait --pipe --collect --quiet`. The command executes in a
transient unit under system.slice, outside the ssh cgroup, so the check
is still real instead of being skipped. Make the MIG probe accept only
Enabled/Disabled. nvidia-driver.yml has the same test; it is left alone
here to avoid conflicting with #1396 and can take the same wrapper after
that lands.
Verified on a DGX B300 (DGX OS 7.5.0, driver 580.126.20) with the guard
active: plain nvidia-smi in the ssh session returns rc=6, while
`sudo systemd-run --wait --pipe --collect --quiet nvidia-smi -L` lists all
eight GPUs with rc=0.
Signed-off-by: 백지명 <wlaud9805@gmail.com>
Summary
Harden GPU-cluster convergence across newer DGX OS, Slurm, and Ubuntu releases:
nv_peer_memtonvidia_peermem.This incorporates and hardens the useful changes proposed in #1389 through #1395. GPU power/clock batching from #1393 remains separate.
Validation
python3 -m unittest discover scripts/validation/tests— 33 tests passed atd1f96221.git diff --check origin/master...HEADpassed.d1f96221, including role lint, syntax checks, and behavior contracts.bc571ff9passed GPU-backed Ubuntu 24.04 first-convergence/runtime validation: login GPU isolation, allocatedsrunGPU access, custom-prefix exporter metrics, Pyxis/Enroot, and exclusive/nonexclusive prolog selection. That evidence does not certify a second full convergence with the login guard already active or the new follow-up commit.Notes
The updated head requires fresh public CI and maintainer review. Full two-OS release QA against the final merged master, including repeated full convergence with login isolation already active, remains required before release. No release certification is claimed for this candidate.