FWIW, doing some deeper looking here:
1. skipping the detach during rescue negative reduces the occurences, but doesn't eliminate them. End up with two instances of long running/hung lvm commands
2. skipping the tempest/api/compute/servers/test_server_rescue_negative.py entirely
We're down to a single case of the long running /hung LVM calls
3. skipping the tempest/scenario/test_encrypted_cinder_volumes.py
We eliminate the problem altogether (at least 4 out of 4 runs so far)
I'm certainly not saying you should remove all of these tests, but I am saying that there's something specific to the behaviors in these tests that causes the LVM to try and query devices that don't exist any longer.
The overwhelming feedback from Nova folks is "we don't do anything to paths here", I still say there's data that says otherwise. At the same time I don't have concrete answers that pass the Nova core test, so I think we'll just live with this scenario in the gate.
FWIW, doing some deeper looking here:
1. skipping the detach during rescue negative reduces the occurences, but doesn't eliminate them. End up with two instances of long running/hung lvm commands
2. skipping the tempest/ api/compute/ servers/ test_server_ rescue_ negative. py entirely
We're down to a single case of the long running /hung LVM calls
3. skipping the tempest/ scenario/ test_encrypted_ cinder_ volumes. py
We eliminate the problem altogether (at least 4 out of 4 runs so far)
I'm certainly not saying you should remove all of these tests, but I am saying that there's something specific to the behaviors in these tests that causes the LVM to try and query devices that don't exist any longer.
The overwhelming feedback from Nova folks is "we don't do anything to paths here", I still say there's data that says otherwise. At the same time I don't have concrete answers that pass the Nova core test, so I think we'll just live with this scenario in the gate.