Bug 1050243 - [RFE] Add Ability to Determine OS Long Name in REST API/SDK
Summary: [RFE] Add Ability to Determine OS Long Name in REST API/SDK
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Juan Hernández
QA Contact: Karolína Hajná
URL:
Whiteboard:
Depends On:
Blocks: 1132506 1156203 1156205
TreeView+ depends on / blocked
 
Reported: 2014-01-08 21:37 UTC by Ted Jones
Modified: 2016-03-09 20:41 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1156203 1156205 (view as bug list)
Environment:
Last Closed: 2016-03-09 20:41:42 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:
sherold: Triaged+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0376 0 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.6.0 2016-03-10 01:20:52 UTC
oVirt gerrit 34225 0 master MERGED restapi: Add collection for operating systems Never

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


Note You need to log in before you can comment on or make changes to this bug.