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

Bug 1542531

Summary:	Allow ServerCPUList and ClusterEmulatedMachines options to be visible over RESTAPI
Product:	[oVirt] ovirt-engine	Reporter:	Simone Tiraboschi <stirabos>
Component:	RestAPI	Assignee:	Martin Perina <mperina>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Radim Hrazdil <rhrazdil>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	4.2.1.4	CC:	bugs, lveyde, michal.skrivanek, mperina, stirabos
Target Milestone:	ovirt-4.2.2	Flags:	rule-engine: ovirt-4.2+
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ovirt-engine-4.2.2	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-03-29 11:10:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Simone Tiraboschi 2018-02-06 14:27:18 UTC

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:

Comment 1 Ondra Machacek 2018-02-06 16:15:11 UTC

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?

Comment 2 Michal Skrivanek 2018-02-06 17:49:56 UTC

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

Comment 3 Simone Tiraboschi 2018-02-07 08:08:04 UTC

(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.

Comment 4 Michal Skrivanek 2018-02-07 09:10:32 UTC

(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.

Comment 5 Simone Tiraboschi 2018-02-07 09:57:42 UTC

(In reply to Michal Skrivanek from comment #4)
> then that should be reported - all of them are supposed to work.

Done

Comment 6 Martin Perina 2018-02-07 15:47:29 UTC

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

Comment 7 Simone Tiraboschi 2018-02-14 10:43:39 UTC

So can the user also change values there via REST API? maybe it could be worth to add also a ReadOnly attribute over ClientAccessLevel.

Comment 8 Martin Perina 2018-02-14 13:26:00 UTC

(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.

Comment 9 Radim Hrazdil 2018-02-26 10:41:48 UTC

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.

Comment 10 Sandro Bonazzola 2018-03-29 11:10:36 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.