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.
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().
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.
In the second paragraph in comment 2 I meant "we *can't* change the meaning".
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
(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.
let's try
Note that we still need to keep the backward compatibility though! So a v3 client would still work.
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'.
Created attachment 1145106 [details] Recent values from WebUI and REST
The suggestion in comment 9 looks good to me.
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