Bug 1466461 - vdsm-client takes at least X4 more than vdsClient
Summary: vdsm-client takes at least X4 more than vdsClient
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Infra
Version: 4.1.3.5
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-4.2.2
: 4.2.2
Assignee: Irit Goihman
QA Contact: Jiri Belka
URL:
Whiteboard:
Depends On: 1381899
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-29 17:22 UTC by Avihai
Modified: 2018-07-20 14:58 UTC (History)
9 users (show)

Fixed In Version: ovirt-engine-4.2.2
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-29 11:07:10 UTC
oVirt Team: Infra
rule-engine: ovirt-4.2+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 83552 0 master MERGED vdsm-tool: configure: load schema 2018-01-30 05:01:07 UTC
oVirt gerrit 83838 0 master MERGED vdsm-api: speed up vdsm-client using pickled schema 2018-02-06 11:29:33 UTC
oVirt gerrit 86749 0 master MERGED vdsmapi: move load yaml action to a method 2018-01-29 08:31:18 UTC
oVirt gerrit 92908 0 master MERGED packaging: Fix requirements for vdsm-client 2018-07-20 14:58:46 UTC
oVirt gerrit 93218 0 ovirt-4.2 MERGED packaging: Fix requirements for vdsm-client 2018-07-22 12:03:01 UTC

Description Avihai 2017-06-29 17:22:17 UTC
Description of problem:
In 4.2 vdsClient is deprecated so using vdsm-client in tests I get timeout failiures.

When I tested both utilities on a 4.1 host I noticed vdsm-client takes X4 than vdsClient .

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

How reproducible:
100%


Steps to Reproduce:
On a 4.1 host with vdsm-client installed do:
1.run 'time vdsClient -s 0 getVdsHardwareInfo'
2.run 'time vdsm-client Host getHardwareInfo'


Actual results:
vdsm-client takes at least X4 more than vdsClient

Expected results:
vdsm-client takes at least X4 more than vdsClient

Additional info:
Taken from client CLI :
[root@storage-ge3-vdsm1 ~]# time vdsClient -s 0 getVdsHardwareInfo
	systemFamily = 'Red Hat Enterprise Linux'
	systemManufacturer = 'Red Hat'
	systemProductName = 'RHEV Hypervisor'
	systemSerialNumber = '4C4C4544-0053-5410-8047-B9C04F465931'
	systemUUID = '07FD09C7-8461-4981-B859-A40C548E10FF'
	systemVersion = '7.2-9.el7_2.1'

real	0m0.382s
user	0m0.272s
sys	0m0.056s

[root@storage-ge3-vdsm1 ~]# time vdsm-client Host getHardwareInfo
{
    "systemProductName": "RHEV Hypervisor", 
    "systemSerialNumber": "4C4C4544-0053-5410-8047-B9C04F465931", 
    "systemFamily": "Red Hat Enterprise Linux", 
    "systemVersion": "7.2-9.el7_2.1", 
    "systemUUID": "07FD09C7-8461-4981-B859-A40C548E10FF", 
    "systemManufacturer": "Red Hat"
}

real	0m1.208s
user	0m0.966s
sys	0m0.111s

Comment 1 Allon Mureinik 2017-06-29 17:28:20 UTC
Avihai - is there any special reason this is on Storage?
It seems like a general infra issue.

Comment 2 Avihai 2017-06-29 17:46:16 UTC
As discussed in the main thread with Piotr Kliczewski , issue has been opened to track this issue.

Comment 3 Piotr Kliczewski 2017-06-30 09:51:00 UTC
I suggest to pickle the schema to a file and package it so the command line client could use it.

Comment 4 Irit Goihman 2017-11-14 08:32:54 UTC
After examining loading pickle schema instead of yaml schema, it looks like running time with pickle is almost twice faster than yaml.

# time vdsm-client Host getHardwareInfo

no changes (yaml schema):

real	0m0.951s
user	0m0.888s
sys	0m0.053s


using pickle schema:

real	0m0.535s
user	0m0.483s
sys	0m0.041s

Comment 5 Jiri Belka 2018-02-22 13:38:17 UTC
ok,

# rpm -qf `which vdsm-client` ; time vdsm-client Host getHardwareInfo
vdsm-client-4.20.19-1.el7ev.noarch
{
    "systemProductName": "PowerEdge M420", 
    "systemUUID": "4C4C4544-004C-4B10-8046-B6C04F313332", 
    "systemSerialNumber": "6LKF132", 
    "systemManufacturer": "Dell Inc."
}

real    0m0.369s
user    0m0.301s
sys     0m0.034s

Comment 6 Sandro Bonazzola 2018-03-29 11:07:10 UTC
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.2 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.


Note You need to log in before you can comment on or make changes to this bug.