Description of problem: 1. When creating a block disk using vdsm testing infrastructure, all the logical volumes are activated by default 2. Volume.prepare does not activate the lvs, so there is no way to test preparing and tearing down volumes. Eventually, we want to be able to test following: 1. block volume created as inactive 2. test verify that volume is invactive before doing prepare 3. test preparing volume 4. test verify that volume was prepared 5. test doing teardown 6. test verify that volume was tore down
The current issue is caused by too much monkeypatching, trying get use untestable legacy code. We have two possible directions: - Improve test doubles used in the tests (e.g FakeSD) so they behave like the actual code (using lvmActivationNamespace etc.) - Setup real block devices for testing using lvm on loop devices, using the real code with minimal monkeypatching. I tried this approach here: https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:guest-lvs Creating loop devices and real lvs on top is hard to do in the tests, because of the event based nature of udev, but I think it is the best way for long term. The only monkeypatching needed is some constants in lvm module, so lvm will detect and use the test loop device (otherwise it uses only multipath devices).
The attached patches are not related, please remove them from the bug.
Still relevant?
(In reply to Allon Mureinik from comment #3) > Still relevant? Yes. These are enhancements that we do want to have.
Closing old bugs, reopen if still needed.
This is required for 4k and other changes in vdsm legacy storage.
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
The infrastructure was merged in master few weeks ago. We have now tests for creating block storage domains and volumes. Moving to modified. I think we can treat this a code change that does not require any QE.
Denis as this bug does not require QE(see prior comment) to verify, can you guys please verify this?
Verified using vdsm tests.
This bugzilla is included in oVirt 4.3.3 release, published on April 16th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.3 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.
resync with Jira
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days