Comment 4 for bug 1473116

Further down the road:

Seems the core issue is libvirts behaviour with changing an images ownership when instantiating a guest from an image. So with the default config (dynamic_ownership = 1) libvirt does change the ownership twice:
When starting the guest the images ownership is set to the libvirts process ownership (as controlled by user & group settings in qemu.conf). When the guest is destroyed later on (e.g. test is teared down) the images ownership is changed to root:root by libvirt.
This seems to be a long standing topic in libvirt discussed e.g. in https://bugzilla.redhat.com/show_bug.cgi?id=547546 and https://www.redhat.com/archives/libvirt-users/2010-January/msg00023.html

This might be interesting for Tempest, as the tests work single by themselves. The issue is the tests using the same image file. As one of the tests instantiates a VM libvirt changes the images permissions and the following tests fail because they cannot access the image any more.

Example test case is shown above:
1) tempest.api.volume.test_volumes_snapshots.VolumesV1SnapshotTestJSON.test_snapshot_create_get_list_update_delete ... ok
2) tempest.api.volume.test_volumes_snapshots.VolumesV1SnapshotTestJSON.test_snapshot_create_with_volume_in_use ... ok
3) tempest.api.volume.test_volumes_snapshots.VolumesV1SnapshotTestJSON.test_snapshots_list_details_with_params ... FAILED
4) tempest.api.volume.test_volumes_snapshots.VolumesV1SnapshotTestJSON.test_snapshots_list_with_params ... FAILED
5) tempest.api.volume.test_volumes_snapshots.VolumesV1SnapshotTestJSON.test_volume_from_snapshot ... FAILED

Test No. 2) instantiates the VM, subsequently all other tests fail.

Now the core issue seems to be libvirts behaviour to me. Until that changes i currently think this could be handled in tempest by removing this side effect from the affected test cases, namely VolumesV2SnapshotTestJSON and VolumesV1SnapshotTestJSON .
Alternatively our driver could interfere and change ownership but that's not a nice solution...