Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1411103 - [CodeChange] Tests infrastructure for block storage
Summary: [CodeChange] Tests infrastructure for block storage
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: vdsm
Classification: oVirt
Component: Core
Version: 4.19.0
Hardware: Unspecified
OS: Unspecified
high
high with 1 vote
Target Milestone: ovirt-4.3.3
: ---
Assignee: Denis Chaplygin
QA Contact: Nir Soffer
URL:
Whiteboard:
Depends On:
Blocks: 1520674 1592916 1639360 1734429
TreeView+ depends on / blocked
 
Reported: 2017-01-08 12:18 UTC by Ala Hino
Modified: 2023-09-12 01:12 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-16 13:58:29 UTC
oVirt Team: Storage
Embargoed:
rule-engine: ovirt-4.3+

Attachments (Terms of Use)

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-12 01:12:59 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days
Note You need to log in before you can comment on or make changes to this bug.