Description of problem: Properly expose supported CPU models from REST APIs. Cluster details returns just a human readable string like 'Intel Haswell-noTSX IBRS Family' or 'AMD Opteron G5' while tools on host side need something like 'model_Haswell-noTSX-IBRS' or 'model_Opteron_G5'. ovirt-engine/api/options/ServerCPUList returns just a 404 HTTP ERROR Version-Release number of selected component (if applicable): ovirt-engine.noarch 4.2.1.5-1.el7.centos How reproducible: 100% Steps to Reproduce: 1. try to get cluster CPU model in machine consumable format 2. 3. Actual results: Just 'Intel Haswell-noTSX IBRS Family' Expected results: Also 'model_Haswell-noTSX-IBRS' somewhere Additional info:
Which tools do you mean? When we are creating a cluster, where we pass the cpu_type, we pass the exact same value as you can see in: ovirt-engine/api/clusterlevels Can you describe the use case more, please?
Simone, I guess you are just saying https://bugzilla.redhat.com/show_bug.cgi?id=1441501#c6 doesn't work. I haven't checked that, but ovirt-web-ui uses that API today without issues
(In reply to Ondra Machacek from comment #1) > ovirt-engine/api/clusterlevels > > Can you describe the use case more, please? On ovirt-engine/api/clusterlevels I get something like <cpu_type> <architecture>x86_64</architecture> <level>12</level> <name>Intel Haswell-noTSX IBRS Family</name> </cpu_type> but I also need model_Haswell-noTSX-IBRS for vm.conf on hosted-engine side. (In reply to Michal Skrivanek from comment #2) > Simone, I guess you are just saying > https://bugzilla.redhat.com/show_bug.cgi?id=1441501#c6 doesn't work. I > haven't checked that, but ovirt-web-ui uses that API today without issues /ovirt-engine/api/options/MigrationPoliciesSupported?version=4.2 (as in the example) works as expected but /ovirt-engine/api/options/ServerCPUList?version=4.2 constantly gives me a 404 HTTP ERROR. I'm not sure that all the VdcOptions values are properly exposed.
(In reply to Simone Tiraboschi from comment #3) > On ovirt-engine/api/clusterlevels I get something like > <cpu_type> > <architecture>x86_64</architecture> > <level>12</level> > <name>Intel Haswell-noTSX IBRS Family</name> > </cpu_type> > > but I also need model_Haswell-noTSX-IBRS for vm.conf on hosted-engine side. that's internal and not usable in any API. The <name> above is what you would use in Cluster definition as CPU Type. I understand why you need that in HE but it shouldn't be part of public API. > I'm not sure that all the VdcOptions values are properly exposed. then that should be reported - all of them are supposed to work.
(In reply to Michal Skrivanek from comment #4) > then that should be reported - all of them are supposed to work. Done
Please bear in mind that not all ConfigValues stored in vdc_options table are exposed using RESTAPI /ovirt-engine/api/options, it depends on theirs ClientAccessLevel: User - users with UserRole or AdminRole can fetch the value over RESTAPI Admin - users with AdminRole can fetch the value over RESTAPI Internal (default value) - not visible over RESTAPI For details please take a look at https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/config/ConfigValues.java#L1604
So can the user also change values there via REST API? maybe it could be worth to add also a ReadOnly attribute over ClientAccessLevel.
(In reply to Simone Tiraboschi from comment #7) > So can the user also change values there via REST API? maybe it could be > worth to add also a ReadOnly attribute over ClientAccessLevel. No, RESTAPI access is readonly. Options exposed via engine-config can be changed by it, all others are completely readonly.
Tested all Admin and User level options, including ServerCPUList mentioned in the description on RHV version 4.2.2. Verified that query for ServerCPUList succeeds, as well as all other options.
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.