Bug 1411103

Summary: [CodeChange] Tests infrastructure for block storage
Product: [oVirt] vdsm Reporter: Ala Hino <ahino>
Component: CoreAssignee: Denis Chaplygin <dchaplyg>
Status: CLOSED CURRENTRELEASE QA Contact: Nir Soffer <nsoffer>
Severity: high Docs Contact:
Priority: high    
Version: 4.19.0CC: aefrat, ahino, alitke, bugs, dchaplyg, ebenahar, fkust, frolland, guillaume.pavese, marceloltmm, nsoffer, tnisan, vjuranek, ylavi
Target Milestone: ovirt-4.3.3Keywords: CodeChange, Reopened
Target Release: ---Flags: rule-engine: ovirt-4.3+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-04-16 13:58:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1520674, 1592916, 1639360, 1734429    

Description Ala Hino 2017-01-08 12:18:18 UTC
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

Comment 1 Nir Soffer 2017-01-08 12:33:00 UTC
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).

Comment 2 Nir Soffer 2017-01-17 10:38:10 UTC
The attached patches are not related, please remove them from the bug.

Comment 3 Allon Mureinik 2017-07-16 16:22:17 UTC
Still relevant?

Comment 4 Ala Hino 2017-07-24 11:09:44 UTC
(In reply to Allon Mureinik from comment #3)
> Still relevant?

Yes. These are enhancements that we do want to have.

Comment 5 Tal Nisan 2018-09-03 08:25:51 UTC
Closing old bugs, reopen if still needed.

Comment 6 Nir Soffer 2018-11-24 01:02:26 UTC
This is required for 4k and other changes in vdsm legacy storage.

Comment 7 Sandro Bonazzola 2019-01-28 09:36:52 UTC
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.

Comment 8 Nir Soffer 2019-03-19 16:02:06 UTC
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.

Comment 9 Avihai 2019-03-26 08:31:15 UTC
Denis as this bug does not require QE(see prior comment) to verify, can you guys please verify this?

Comment 10 Nir Soffer 2019-03-28 17:24:48 UTC
Verified using vdsm tests.

Comment 11 Sandro Bonazzola 2019-04-16 13:58:29 UTC
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.

Comment 12 Franta Kust 2019-06-03 09:08:02 UTC
resync with Jira

Comment 13 Red Hat Bugzilla 2023-09-14 03:37:03 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days