Skip to content

fix: harden GPU runtime convergence - #1396

Closed
dholt wants to merge 2 commits into
masterfrom
dholt/release-26.09-blockers
Closed

dholt wants to merge 2 commits into
masterfrom
dholt/release-26.09-blockers

Conversation

@dholt

@dholt dholt commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Summary

Harden GPU-cluster convergence across newer DGX OS, Slurm, and Ubuntu releases:

  • Select the correct SSH service when applying the Slurm login GPU guard.
  • Transition safely from legacy nv_peer_mem to nvidia_peermem.
  • Make exclusive-job detection custom-prefix aware and fail closed on invalid Slurm query results.
  • Use a command-scoped Enroot AppArmor profile without relaxing the host-wide user-namespace policy.
  • Select and verify the DGX OS 7 DCGM 4 package on Ubuntu 24.04 and newer.
  • Expose custom-prefix Slurm client binaries to the exporter through read-only mounts.
  • Keep privileged driver/CUDA checks, GPU clock operations, and MIG administration outside the SSH login GPU cgroup using synchronous transient systemd services. This addresses subsequent full Ansible convergence after login isolation is already active.
  • Require successful MIG capability detection before installation on both Debian and Red Hat families; avoid shell interpolation for GPU clock arguments.

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 at d1f96221.
  • git diff --check origin/master...HEAD passed.
  • Public-content sanitizer passed for the candidate changes and this PR body.
  • Exact-commit static release QA previously passed at d1f96221, including role lint, syntax checks, and behavior contracts.
  • The preceding commit bc571ff9 passed GPU-backed Ubuntu 24.04 first-convergence/runtime validation: login GPU isolation, allocated srun GPU 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.

@dholt
dholt force-pushed the dholt/release-26.09-blockers branch from adbefea to bc571ff Compare September 4, 2026 22:23
@dholt
dholt marked this pull request as ready for review September 4, 2026 23:08
@dholt
dholt requested a review from michael-balint September 4, 2026 23:08
@dholt dholt changed the title Fix GPU runtime convergence across Slurm deployment paths fix: harden GPU runtime convergence Sep 4, 2026
@100milliongold

Copy link
Copy Markdown
Contributor

Thanks for pulling these together, and for the hardening on top — several of the
changes here fix real gaps in what I proposed. Adding apparmor to
pyxis_ubuntu_deps is one: my version would have failed on a minimal install
where apparmor_parser is absent. set -o pipefail, the fail-closed
num_jobs=1 default, and rejecting a zero node count are all stricter than what
I had.

One request on attribution. The body credits #1389#1395, which I appreciate,
but the single squashed commit lists one author, so the contributions won't show
up in git log, git blame, or the contributor graph. Would you consider adding
Co-authored-by: trailers before this merges? For my part:

Co-authored-by: 100milliongold <je.kim@xiilab.com>

#1389, #1390 and #1394 came from a different contributor (@100-JM) — their
address is in those commits if you'd like to include them too.

Happy to close #1391, #1392 and #1395 once this lands. #1393 stays open as you
noted.

@100-JM

100-JM commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

Following up on the attribution point above for #1389, #1390 and #1394, which this PR incorporates (the ssh_unit selection, the nvidia_peermem probe with the legacy nv_peer_mem transition, and the DGX OS DCGM package handling).

I appreciate the extra hardening — the /sys/module/nv_peer_mem check before unloading and the post-install DCGM assert are both stricter than what I had. Since the squashed commit carries a single author, could you add a Co-authored-by: trailer so the contribution stays visible in git log and the contributor graph? The address matches the DCO sign-off on those commits:

Co-authored-by: 백지명 <wlaud9805@gmail.com>

I'll close #1389, #1390 and #1394 once this lands. #1397 (running the remaining nvidia-smi tasks outside the ssh cgroup) is newer and not covered here, so it stays open.

@lannex

lannex commented Sep 7, 2026

Copy link
Copy Markdown

@dholt
As a fellow developer, I must express my deep disappointment with how the commits in this PR were handled.

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.

@dholt
dholt marked this pull request as draft September 10, 2026 17:35
dholt and others added 2 commits September 10, 2026 11:40
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>
@dholt
dholt force-pushed the dholt/release-26.09-blockers branch from d1f9622 to 4cd3944 Compare September 10, 2026 17:40
@dholt

dholt commented Sep 10, 2026

Copy link
Copy Markdown
Contributor Author

@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.

@dholt dholt closed this Sep 10, 2026
100-JM added a commit to 100-JM/deepops that referenced this pull request Sep 11, 2026
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>
dholt pushed a commit that referenced this pull request Sep 11, 2026
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants