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

Bug 1187752

Summary: Hypervisor CPU family and name mismatch between API and webUI
Product: [oVirt] ovirt-engine Reporter: Jake Hunsaker <jhunsaker>
Component: RestAPIAssignee: Marek Libra <mlibra>
Status: CLOSED CURRENTRELEASE QA Contact: Israel Pinto <ipinto>
Severity: medium Docs Contact:
Priority: medium    
Version: ---CC: bazulay, bugs, gklein, juan.hernandez, lsurette, michal.skrivanek, rbalakri, Rhev-m-bugs, sbonazzo, srevivo, ykaul
Target Milestone: ovirt-4.0.0-betaFlags: rule-engine: ovirt-4.0.0+
rule-engine: planning_ack+
michal.skrivanek: devel_ack+
mavital: testing_ack+
Target Release: 4.0.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-04 13:28:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Recent values from WebUI and REST none

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):
rhevm-3.4.4-2.2

How reproducible:
Always

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

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 

and 

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: 4.0.2.3-0.1.el7ev
HOST:
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-4.18.5.1-1.el7ev
SPICE Version:0.12.4 - 15.el7_2.1

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

Results:
PASS