Bug 1187752 - Hypervisor CPU family and name mismatch between API and webUI
Summary: Hypervisor CPU family and name mismatch between API and webUI
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RestAPI
Version: ---
Hardware: x86_64
OS: Linux
Target Milestone: ovirt-4.0.0-beta
: 4.0.0
Assignee: Marek Libra
QA Contact: Israel Pinto
Depends On:
TreeView+ depends on / blocked
Reported: 2015-01-30 19:27 UTC by Jake Hunsaker
Modified: 2016-08-04 13:28 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-08-04 13:28:31 UTC
oVirt Team: Virt
rule-engine: ovirt-4.0.0+
rule-engine: planning_ack+
michal.skrivanek: devel_ack+
mavital: testing_ack+

Attachments (Terms of Use)
Recent values from WebUI and REST (10.65 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-04-08 12:21 UTC, Marek Libra
no flags Details

System ID Private Priority Status Summary Last Updated
oVirt gerrit 56375 0 master MERGED webadmin: Unify CPU Family naming 2016-04-26 07:50:59 UTC

Description Jake Hunsaker 2015-01-30 19:27:31 UTC
Description of problem:

From the API, when the get_cpu().get_name() method is used the specific processor model is given, e.g.:

>>> host.get_cpu().get_name()
'Intel(R) Xeon(R) CPU           E5649  @ 2.53GHz'

However, in the portal a hypervisor's CPU family is reported under "CPU Name" and the specific model is given by "CPU Type". 

Additionally, the hypervisor's CPU family cannot be queried (maybe due to this mismatch?) and the get_hardware_information().get_family() method seems to return the product family from dmidecode (this is a bit confusing):

>>> host.get_hardware_information().family
'System x'

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

How reproducible:

Steps to Reproduce:
1. Use get.cpu().get_family() and get_hardware_information().get_family()

Actual results:
get_cpu().get_family() returns the specific processor model
get_hardware_information.get_family() returns the vendor family string

Expected results:
Either one of the get_family() methods should return the processor family name (I.E. 'Intel Westmere Family').

If get_hardware_information().get_family() is _supposed_ to return the vendor family string, perhaps this method should be called 'get_product_family()' instead.

Additional info:

I'm not sure if the portal's display of the the CPU family next to "CPU Name" and the specific model next to "CPU Type" is also a bug or if this is the intended design, but regardless there is a mismatch somewhere here.

Comment 1 Jake Hunsaker 2015-01-30 20:06:24 UTC
Typo correction:

get_cpu().get_family() should be get_cpu().get_name() in Actual Results 


Expected Results:
Either get_name() should return the family like the portal, or there should be a get_family() method for get_cpu().

Comment 2 Juan Hernández 2015-02-02 11:11:32 UTC
In the REST API the concept of "name" corresponds to the backend concept of "model", so in these regards I think it is implemented correctly.

We don't currently a have a concept of "CPU family" or "CPU type". This could be added and populated with the value returned by "VDS.getCpuName().getCpuName()", which seems to be what the GUI is doing. What we can do is change the meaning of the existing "name" attribute, as that would break backwards compatibility.

Regarding the "hardware_information" element, we can't change the names or meanings of existing elements because of backwards compatibility.

So the only thing we can do to improve the situation here is to add the "cpu.family" attribute. Not sure if this is very useful, because you can already get that information from the "cluster.cpu.id" attribute.

Comment 3 Juan Hernández 2015-02-02 11:12:51 UTC
In the second paragraph in comment 2 I meant "we *can't* change the meaning".

Comment 4 Michal Skrivanek 2015-09-07 12:37:41 UTC
since we can't really change meaning maybe we can do a bigger change in 4.0...to add new fields/names and finally remove the old ones in 4.1

Comment 6 Yaniv Kaul 2016-03-10 15:15:41 UTC
(In reply to Michal Skrivanek from comment #4)
> since we can't really change meaning maybe we can do a bigger change in
> 4.0...to add new fields/names and finally remove the old ones in 4.1

Now's the time - I'm in favor.

Comment 7 Michal Skrivanek 2016-03-24 14:53:56 UTC
let's try

Comment 8 Yaniv Kaul 2016-03-24 15:23:22 UTC
Note that we still need to keep the backward compatibility though! So a v3 client would still work.

Comment 9 Marek Libra 2016-04-08 12:20:16 UTC
Before changing anything, let's agree on scope of this bug.

I've gathered data from two hosts in two different setups - my master dev with virtualized host and one from the 3.6.5 QA setups. Unfortunately I don't have access to better sources.
The resulting comparison table are attached as 'cpu__host_Cluster_UI.ods'.

As mentioned in comment 2, the processor family name (like Intel SandyBridge Family) can be queried on cluster.cpu.id (or cluster.cpu.type) so I would vote for not introducing duplicity by adding the 'family' to the 'host' resource.

The only confusion I see is in using host.cpu.name vs. WebUI's 'CPU Model' for the same thing.
To unify that, I propose change of WebUI label from recent 'CPU Model' to 'CPU Model Name'.

Comment 10 Marek Libra 2016-04-08 12:21:21 UTC
Created attachment 1145106 [details]
Recent values from WebUI and REST

Comment 11 Juan Hernández 2016-04-08 12:43:16 UTC
The suggestion in comment 9 looks good to me.

Comment 12 Israel Pinto 2016-08-03 08:46:18 UTC
Verify on:
RHVM Version:
OS Version:RHEL - 7.2 - 9.el7_2.1
OS Description:Kernel Version:3.10.0 - 327.22.2.el7.x86_64
KVM Version:2.3.0 - 31.el7_2.20
LIBVIRT Version:libvirt-1.2.17-13.el7_2.5
VDSM Version:vdsm-
SPICE Version:0.12.4 - 15.el7_2.1

Check via REST cpu.name and compare with UI host->hardware->CPU Model Name are the same


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