You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e9fa277
Browse filesBrowse the repository at this point in the historyBrowse files
test(tmachine): assert CDI scenario behavior in a Docker guest
Add a cdi feature suite that creates a sandbox for each CDI scenario
by selecting its device explicitly with --gpu 1 and the Docker
cdi_devices driver option, then checks what the workload observes or
that creation is rejected. The sandbox only reports facts; the test
makes every assertion, so a failure names the check that disagreed.
Each scenario is its own test.
The expectations record the behavior the sandbox has today, loaded
from the scenarios.json published by the fixtures role. A
OPENSHELL_CDI_CAPTURE mode prints observations instead of asserting,
to record that behavior for a new scenario.
The test playbook enables caller driver configuration in the installed
gateway's active TOML for the run and restores it afterwards. Build the
suite's nextest archive in tests/artifacts.nix, expose it as
build-artifacts-cdi-tests, and run the suite on the Docker environment
with the deb installer in the branch and release matrices.
Signed-off-by: Evan Lezar <elezar@nvidia.com>
|`mount-under-read-only-baseline`| File at `/usr/share/tmachine-cdi/baseline-read-only-file`, under a directory the sandbox already makes read-only | Read succeeds, write denied. | Unchanged. |
375
+
|`read-only-file`| File at `/tmachine-cdi/read-only/file`| Read and write denied. | Read succeeds outside the baseline grants; write fails. |
376
+
|`read-only-directory`| Directory at `/tmachine-cdi/read-only/directory`| Reading its marker and creating files denied. | Reading its marker succeeds; write fails. |
377
+
|`library-parent`| Marker named `/tmachine-cdi/library/libfixture.so.1`| Read and write denied. | Resolver derives the library parent; the marker is not an actual shared library. |
378
+
|`broad-library-parent`| Marker named `/libtmachinefixture.so.1`| Read and write denied. | Launch rejects expansion to `/`. |
379
+
|`writable-file`| Writable file at `/tmachine-cdi/writable/file`| Read and write denied. | Launch rejects it even with exact or ancestor write grants. |
380
+
|`writable-directory`| Writable directory at `/tmachine-cdi/writable/directory`| Write denied. | Launch rejects it even with exact or ancestor write grants. |
381
+
|`omitted-access-file`| Bind without `ro` or `rw`| Read and write denied. | Effective writable access causes launch rejection. |
382
+
|`device-node`| Null character device at `/dev/tmachine-cdi-null`| Non-root, write denied. | Non-root read/write succeeds; an exact authored read-only entry fails launch. |
383
+
|`device-node-with-gid`| Group-restricted null device at `/dev/tmachine-cdi-group-null`| Non-root with the device's group, write denied. | The generated supplementary GID permits non-root access. |
384
+
|`unix-socket`| Echo socket at `/tmachine-cdi/socket/echo.sock`| Sibling file in the host directory is not visible. | Socket communication succeeds without deriving parent filesystem grants. |
385
+
386
+
Every scenario also supplies a spec-level environment marker and a read-only
387
+
mount at `/usr/share/tmachine-cdi/common/spec-marker`, allowing checks of
388
+
spec/device edit merging without depending on derived grants. The device group
389
+
is allocated in the disposable guest. A systemd socket unit restores the echo
390
+
endpoint after reboot; the existing tmpfiles configuration restores the
391
+
scenario spec. Negative scenarios must be selected individually, not combined
392
+
with positive cases.
393
+
394
+
The role publishes each scenario's expectations as `scenarios.json` next to the
395
+
fixtures. The `scenario_*` tests load them and assert the behavior recorded in
396
+
`vars/scenarios.yaml`, which is the sandbox's behavior today. A change that
397
+
alters a scenario's behavior, such as #4204 deriving grants from the spec,
398
+
updates those values in the same diff. To record the current behavior, run the
399
+
tests with `OPENSHELL_CDI_CAPTURE=1` set for the test process; they then print
400
+
what each scenario observed instead of asserting.
401
+
402
+
To add a scenario, add an entry to `cdi_scenarios` in
403
+
`tests/ansible/roles/cdi_fixtures/vars/scenarios.yaml` with the host fixtures
404
+
it needs, its CDI edits, and its `expect` (the checks on the workload, or a
405
+
rejection), then list it in `cdi_scenarios!` in
406
+
`tests/suites/features/cdi/tests/injection.rs`. A new spec file belongs in
407
+
`cdi_fixture_spec_files` in the role defaults, which the setup and test
408
+
playbooks share.
409
+
410
+
Directory absence, daemon configuration refresh, and restart tests require
411
+
orchestration around these fixtures. Spec projection secrecy is a separate
412
+
workload assertion. Hardware CUDA initialization remains outside this suite.
413
+
343
414
Print the exact tmachine archive selection as a shell `PODMAN_CI_TESTS` array:
0 commit comments