The combination of using parametrization to avoid creating different tests that only differ by one parameter but rely on the same running VM (module scope fixture), pytest's handling of setup and teardown, and the presence of too many different tests in a single file make this fail:
pytest tests/storage/ext/ --hosts=172.16.210.148 -m "not hostA2 and not hostB1" -k "not quicktest" --log-cli-level=debug
What happens is that a host reboot happens between the two "versions" of tests/storage/ext/test_ext_sr.py::TestEXTSR::test_coalesce : snapshot, and clone. So, in-between, the running VM gets shut down.
This is something that we don't see in CI, as we extracted the "reboot" tests to a separate job running on hosts that reboot fast. But in any case, I think the fixture management for these "running VMs with randstream in it" is a bit fragile.
The combination of using parametrization to avoid creating different tests that only differ by one parameter but rely on the same running VM (module scope fixture), pytest's handling of setup and teardown, and the presence of too many different tests in a single file make this fail:
What happens is that a host reboot happens between the two "versions" of tests/storage/ext/test_ext_sr.py::TestEXTSR::test_coalesce : snapshot, and clone. So, in-between, the running VM gets shut down.
This is something that we don't see in CI, as we extracted the "reboot" tests to a separate job running on hosts that reboot fast. But in any case, I think the fixture management for these "running VMs with randstream in it" is a bit fragile.