Bug 1050243

Summary:	[RFE] Add Ability to Determine OS Long Name in REST API/SDK
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Ted Jones <tejones>
Component:	ovirt-engine	Assignee:	Juan Hernández <juan.hernandez>
Status:	CLOSED ERRATA	QA Contact:	Karolína Hajná <khajna>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	3.3.0	CC:	bazulay, gklein, ichute, iheim, juan.hernandez, lsurette, michal.skrivanek, pstehlik, rbalakri, Rhev-m-bugs, sherold, syu, yeylon, ykaul
Target Milestone:	ovirt-3.6.0-rc	Keywords:	FutureFeature
Target Release:	3.6.0	Flags:	sherold: Triaged+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:
Clones:	1156203 1156205 (view as bug list)		Environment:
Last Closed:	2016-03-09 20:41:42 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:
Bug Depends On:
Bug Blocks:	1132506, 1156203, 1156205

Description Ted Jones 2014-01-08 21:37:35 UTC

Description of problem:

In the oVirt Open Virtualization Manager, the operating system for a VM is displayed with a full textual value, but the OS type is a short value in the SDK. For example, an operating system type of "rhel_6x64" is displayed as "Red Hat Enterprise Linux 6.x x64" in the manager. This mapping is not available in the REST API/SDK.

<Juan Hernandez>
The long name of the operating system isn't available in the RESTAPI,
and thus it isn't available in any of the SDKs either.

The GUI can obtain it because it has direct access to the backend,
bypassing the RESTAPI. In the future the GUI won't be allowed to bypass
the the RESTAPI, so eventually we will have to make it available in the
RESTAPI. 
</Juan Hernandez>

Ideally, I would like to have this feature for RHEV/SAP LVM adapter due by mid-March. If not, I will need a workaround.


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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Michal Skrivanek 2014-01-17 10:09:03 UTC

Since the mapping and also the value is configurable in osinfo on the engine we would probably need a specific new query to get the complete mapping id, short name and full name.

Comment 3 Juan Hernández 2014-01-17 10:52:48 UTC

From the API modeling point of view I think that we should add a read only top level collection /operatingsystems with the following content:

  <operating_systems>
    <operating_system href="/operatingsystems/rhel_6" id="rhel_6">
      <name>Red Hat Enterprise Linux 6.x</name>
    </operating_system>
    <operating_system href="/operatingsystems/windows_7" id="windows_7">
      <name>Windows 7</name>
    </operating_system>
    ...
  </operating_systems>

This is enough for the requirement in the description, and gives us room for future enhancements.

We should also deprecate (but preserve, for backwards compatibility) the existing <os_type> elements inside the /capabilities resource.

Comment 4 Itamar Heim 2014-09-21 10:28:35 UTC

this should be reviewed for 3.6 as part of moving the GUI to be on top of the REST API
einav - i think there is some tracker bug?

Comment 5 Einav Cohen 2014-10-01 23:26:51 UTC

(In reply to Itamar Heim from comment #4)
> einav - i think there is some tracker bug?

added.

Comment 6 Karolína Hajná 2015-04-14 12:38:34 UTC

Verified on oVirt 3.6.0-1


The added content is following:

<operating_systems>
...
  <operating_system href= "/api/operatingsystems/19" id="19">
    <name>rhel_6x64</name>
    <description>Red Hat Enterprise Linux 6.x x64</description>
  </operating_system>
  <operating_system href= "/api/operatingsystems/1003" id="1003">
    <name>rhel_6_ppc64</name>
    <description>Red Hat Enterprise Linux 6.x</description>
  </operating_system>
...
</operating_systems>

Comment 9 errata-xmlrpc 2016-03-09 20:41:42 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-0376.html