cuda.bindings.nvml: Correctly handle a test requiring root

[mdboom]

The cuda.bindings.nvml tests were written with the assumption that they would be run by a non-root user (as is the case in our CI). SWQA seemingly is running some tests as root, which then causes the test to fail. This change makes the test robust to either situation.

[copy-pr-bot]

Auto-sync is disabled for ready for review pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[mdboom]

/ok to test

[github-actions]

Doc Preview CI
🚀 View preview at https://nvidia.github.io/cuda-python/pr-preview/pr-1515/
https://nvidia.github.io/cuda-python/pr-preview/pr-1515/cuda-core/
https://nvidia.github.io/cuda-python/pr-preview/pr-1515/cuda-bindings/
https://nvidia.github.io/cuda-python/pr-preview/pr-1515/cuda-pathfinder/
Preview will be ready when the GitHub Pages deployment is complete.

[mdboom]

/ok to test

[mdboom]

/ok to test

[mdboom]

This is proving to be a challenge. On some of our CI runners, all signs indicate that the user is the root user (uid == 0, a member of gid == 0) etc., but the API call still fails as NoPermissionError. I suspect this is because the user is root inside a container, and the actual thing (device handle, maybe) that this API is trying to access requires root outside of the container.

We know, however, that SWQA has able to run as root and get this API call to pass (which then caused the original test to fail).

I'm thinking I'll just rewrite the test so that it will be robust to the call failing or passing regardless of the user's status, but that's a workaround.

Anyone else run into this issue and have a better solution?

[kkraus14]

@mdboom since nvml does some pretty low level system interactions, things can be somewhat arbitrarily blocked off via things like seccomp policies even if we can detect we're in a container or anything else reasonable.

I think your approach of treating getting nvml.NoPermissionError as either a skip or a success sounds reasonable to me. I don't know if it makes sense for us to chase marking tests for it versus just having a blanket policy.

[mdboom]

/ok to test