Comment 4 for bug 1473116

Revision history for this message
Silvan Kaiser (2-silvan) wrote :

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 and

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