Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1520674

Summary:	[RFE] Add a new API verb to fetch all the volumes' info from a storage domain
Product:	[oVirt] vdsm	Reporter:	Maor <mlipchuk>
Component:	Core	Assignee:	Eyal Shenitzky <eshenitz>
Status:	CLOSED DEFERRED	QA Contact:	Avihai <aefrat>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	---	CC:	bugs, nsoffer, tnisan
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	rule-engine: ovirt-4.3? rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack?
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	DR
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-04-01 14:47:16 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:	1411103
Bug Blocks:	1652540

Description Maor 2017-12-04 22:28:42 UTC

Description of problem:
As part of the attach operation of a storage domain we fetch all the images from the storage domain and check each image whether it is an OVF_STORE disk or not.
To get the description of the image, the engine calls the verb getVolumeInfo for each of the images fetched from the storage domain.
This back and forward communication is redundant and takes a long time for the storage domain to be attached.
We could gain better performance if VDSM will provide a new verb which will return a list of all the volumes' info in one operation.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
We fetch all the images and go one by one to call getVolumeInfo

Expected results:
One verb which will return all the volumes' info

Additional info:

Comment 1 Maor 2017-12-04 22:30:41 UTC

Note: Once the verb will be implemented, a corresponding bug should be opened for the engine to use it as part of attach storage domain

Comment 2 Yaniv Kaul 2017-12-05 05:47:38 UTC

Severity?

Comment 3 Maor 2017-12-05 07:22:48 UTC

(In reply to Yaniv Kaul from comment #2)
> Severity?

I've already set the severity to medium.
Is it enough, or should I set it also else where?

Comment 4 Allon Mureinik 2017-12-05 12:02:04 UTC

(In reply to Maor from comment #3)
> (In reply to Yaniv Kaul from comment #2)
> > Severity?
> 
> I've already set the severity to medium.
> Is it enough, or should I set it also else where?

I'd like to prioritize this, it's an enabler for DR.

Comment 6 Nir Soffer 2018-11-24 01:23:38 UTC

It is not clear if engine needs all volumes info, or only the info for the top
volume in each image.

Since volume metadata is stored in one file per volume, or one block in the
metadata per volume, collecting all volumes metadata can take lot of time on 
vdsm side, and the call can time out. This probably be done in async call.

There are no measurements here, so we don't know if providing a new verb is
indeed the right solution. We need to measure the current code with a big storage
domain (e.g. 1000 disks), and check how time is spent.

Collecting all volume info at once may be slower then getting volumes one
by one, since engine can process the volumes immediately after receiving the first
volume, but when fetching all volumes at once, it must wait until all volumes are
fetched before doing anything.

Collecting multiple volume info at the same time add the problem of handling
error during collection - should vdsm skip volumes that could not be fetched, or
fail the entire operation? How errors fetching single volume should be returned?

Comment 7 Sandro Bonazzola 2019-01-28 09:36:41 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 Michal Skrivanek 2020-03-18 15:46:13 UTC

This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 9 Michal Skrivanek 2020-03-18 15:51:05 UTC

This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 10 Michal Skrivanek 2020-04-01 14:47:16 UTC

ok, closing. Please reopen if still relevant/you want to work on it.

Comment 11 Michal Skrivanek 2020-04-01 14:50:55 UTC

ok, closing. Please reopen if still relevant/you want to work on it.