Bug 1110798 - SDK and REST ignore template's disk attributes
Summary: SDK and REST ignore template's disk attributes
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-api
Version: 3.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: m1
: 3.6.0
Assignee: Amit Aviram
QA Contact: Ori Gofen
Whiteboard: storage
Depends On:
Blocks: 1199811 1222283
TreeView+ depends on / blocked
Reported: 2014-06-18 13:19 UTC by Raz Tamir
Modified: 2016-03-10 06:11 UTC (History)
6 users (show)

Fixed In Version: ovirt-engine-3.6.0-0.0.master.20150412172306.git55ba764
Doc Type: Bug Fix
Doc Text:
Cause: When adding a template via REST API and providing its new disk's alias, the action succeeded but the disk's alias was not changed. Consequence: The user can provide an alias but cannot know that it will not actually be changed. Fix: New template's disk alias is changeable now. Result: The fields which are specified in the new template request's signature are available for usage. among them is the disk's alias.
Clone Of:
: 1199811 1222283 (view as bug list)
Last Closed: 2015-11-04 11:34:16 UTC
oVirt Team: Storage

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
oVirt gerrit 37808 0 master MERGED restapi: Extending disk editing when adding a new template. Never
oVirt gerrit 40986 0 ovirt-engine-3.5 MERGED restapi: Extending disk editing when adding a new template. Never

Description Raz Tamir 2014-06-18 13:19:25 UTC
Description of problem:
When trying to create a template from SDK or REST api, there is an option to select the alias of the template's disk.

In REST (for example):
<vm id='4c5d042e-bd34-4280-a0eb-2985863ffb15'>
        <disk id='2b997211-ad7a-48ba-b2f0-cf3264ea4447'>

The new created template id is: 15c4415c-205d-474d-a626-6b7c29caac94

The response: in /api/templates/15c4415c-205d-474d-a626-6b7c29caac94/disks

<disk href= "/api/templates/15c4415c-205d-474d-a626-6b7c29caac94/disks/50bfde29-379b-4cdf-b629-e2538f4464c1" id="50bfde29-379b-4cdf-b629-e2538f4464c1">
<link href= "/api/templates/15c4415c-205d-474d-a626-6b7c29caac94/disks/50bfde29-379b-4cdf-b629-e2538f4464c1/export" rel="export"/>
<link href= "/api/templates/15c4415c-205d-474d-a626-6b7c29caac94/disks/50bfde29-379b-4cdf-b629-e2538f4464c1/copy" rel="copy"/>
<name>vm_99_Disk1</name>   ********* NOT AS EXPECTED *********
<template href= "/api/templates/15c4415c-205d-474d-a626-6b7c29caac94" id="15c4415c-205d-474d-a626-6b7c29caac94"/>
<storage_domain id="5b5b33a0-ca1f-476f-82f0-ccb06437283b"/>

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

How reproducible:

Steps to Reproduce:
1. POST in /api/templates/ :
<vm id={vm_id}>
        <disk id={disk_id}>

2. Check the response body

Actual results:
In the response body under the vm_id/disks, check the newly created disk's alias

Expected results:
the disk's alias should be like the alias that sent in the request body

Additional info:

Comment 1 Amit Aviram 2015-02-16 09:05:04 UTC
This is actually a wider bug than what is described- Any field which is specified in the REST XML regarding the new template's disks is ignored.

Comment 2 Amit Aviram 2015-03-08 14:34:44 UTC
The patch added now makes the REST request for a new template to be correlated with the rsdl_metadata file, which specifies what can be posted and what not.

Disk's alias is now specified there and can be changed via REST.

Comment 3 Ori Gofen 2015-05-07 13:13:54 UTC
This bug has reproduced on ovirt3.6 master.

steps taken:
curled a Post call to engine

[root@ovirt-gofen-2 Rest-Api-Qe]# cat template.xml
<vm id="5e7816d7-12a0-4cb5-ad06-33fbf72077f4">
        <disk id="cb8d7c33-dcc4-4670-8189-05628389f67e">

viewed the template object from the ui and rest, disk's original name apears instead of the new name

Comment 4 Amit Aviram 2015-05-12 08:41:39 UTC
Apparently this happens only Gluster storage and works on NFS. We will investigate further.

Comment 5 Amit Aviram 2015-05-12 11:21:53 UTC
After checking again on Gluster it seemed to work as well. 

Regarding the test that was made: currently the vm's disk in the tested environment is not "cb8d7c33-dcc4-4670-8189-05628389f67e", so maybe template.xml should be fixed and tested again? (The vm's disk's ID is "0b8550c3-d6a4-401c-9775-eb0541add05d")

Maybe there were changes, but it is likely that the environment wasn't change since the test..

Comment 6 Ori Gofen 2015-05-12 12:16:22 UTC
verified on oVirt3.6 master

Comment 7 Sandro Bonazzola 2015-11-04 11:34:16 UTC
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue.
If problems still persist, please open a new BZ and reference this one.

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