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