+++ This bug was initially created as a clone of Bug #1050243 +++

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:

--- Additional comment from John Skeoch on 2014-01-12 20:48:21 EST ---

User edolinin's account has been closed

--- Additional comment from Michal Skrivanek on 2014-01-17 05:09:03 EST ---

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.

--- Additional comment from Juan Hernández on 2014-01-17 05:52:48 EST ---

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.

--- Additional comment from Itamar Heim on 2014-09-21 06:28:35 EDT ---

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?

--- Additional comment from Einav Cohen on 2014-10-01 19:26:51 EDT ---

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

added.