+++ This bug was initially created as a clone of Bug #1110798 +++ 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): <template> <name>temp_from_1</name> <vm id='4c5d042e-bd34-4280-a0eb-2985863ffb15'> <disks> <disk id='2b997211-ad7a-48ba-b2f0-cf3264ea4447'> <alias>new_name</alias> </disk> </disks> </vm> </template> 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"> <actions> <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"/> </actions> <name>vm_99_Disk1</name> ********* NOT AS EXPECTED ********* <template href= "/api/templates/15c4415c-205d-474d-a626-6b7c29caac94" id="15c4415c-205d-474d-a626-6b7c29caac94"/> <alias>vm_99_Disk1</alias> <image_id>eb6bfa68-bfbe-48ba-aa62-3377105383b6</image_id> <storage_domains> <storage_domain id="5b5b33a0-ca1f-476f-82f0-ccb06437283b"/> </storage_domains> <provisioned_size>5368709120</provisioned_size> <actual_size>1073741824</actual_size> <status> <state>ok</state> </status> </disk> Version-Release number of selected component (if applicable): ovirt-engine-3.5.0-0.0.master.20140605145557.git3ddd2de.el6.noarch How reproducible: 100% Steps to Reproduce: 1. POST in /api/templates/ : 1.1 <template> <name>temp_from_1</name> <vm id={vm_id}> <disks> <disk id={disk_id}> <alias>new_name</alias> </disk> </disks> </vm> </template> 2. Check the response body 3. 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: --- Additional comment from Amit Aviram on 2015-02-16 04:05:04 EST --- 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. --- Additional comment from Amit Aviram on 2015-03-08 10:34:44 EDT --- 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. --- Additional comment from Ori Gofen on 2015-05-07 09:13:54 EDT --- 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 <template> <name>temp_from_rest</name> <vm id="5e7816d7-12a0-4cb5-ad06-33fbf72077f4"> <disks> <disk id="cb8d7c33-dcc4-4670-8189-05628389f67e"> <alias>new_name</alias> </disk> </disks> </vm> </template> viewed the template object from the ui and rest, disk's original name apears instead of the new name --- Additional comment from Amit Aviram on 2015-05-12 04:41:39 EDT --- Apparently this happens only Gluster storage and works on NFS. We will investigate further. --- Additional comment from Amit Aviram on 2015-05-12 07:21:53 EDT --- 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.. --- Additional comment from Ori Gofen on 2015-05-12 08:16:22 EDT --- verified on oVirt3.6 master
doctext copied from bug 1199811.
Since oVirt 3.5.4 RC1 has been released, please ensure that the fix is included in the build and move the bug to ON_QA accordingly.
Issue reproduced using vt16.1 (rhevm-3.5.4-1.1.el6ev.noarch) send - <template> <name>temp_from_rest</name> <vm id="b2b269d0-7cb7-4fd1-a098-c3014d194070"> <disks> <disk id="11c1dbe3-035b-49c9-8ae6-58214f4881c7"> <alias>new_name</alias> </disk> </disks> </vm> </template> get - <disks> <disk href= "/api/templates/cf3767e1-005c-4f1c-b7b8-edc0bfe98e59/disks/cbb7d264-5204-4db1-a58e-e8e555172458" id="cbb7d264-5204-4db1-a58e-e8e555172458"> <actions> <link href= "/api/templates/cf3767e1-005c-4f1c-b7b8-edc0bfe98e59/disks/cbb7d264-5204-4db1-a58e-e8e555172458/export" rel="export"/> <link href= "/api/templates/cf3767e1-005c-4f1c-b7b8-edc0bfe98e59/disks/cbb7d264-5204-4db1-a58e-e8e555172458/copy" rel="copy"/> </actions> <name>vm_Disk1</name> <template href= "/api/templates/cf3767e1-005c-4f1c-b7b8-edc0bfe98e59" id="cf3767e1-005c-4f1c-b7b8-edc0bfe98e59"/> <alias>vm_Disk1</alias> <image_id>292813e3-f701-4864-8cc9-1128294edd99</image_id> <storage_domains> <storage_domain id="95056e58-4790-4792-8685-2289356a8535"/> </storage_domains> <size>5368709120</size> <provisioned_size>5368709120</provisioned_size> <actual_size>5368709120</actual_size> <status> <state>ok</state> </status> <interface>virtio</interface> <format>raw</format> <sparse>false</sparse> <bootable>true</bootable> <shareable>false</shareable> <wipe_after_delete>false</wipe_after_delete> <propagate_errors>false</propagate_errors> <disk_profile href= "/api/diskprofiles/f1a7deec-95c9-4a38-b1b2-a20303e3ea35" id="f1a7deec-95c9-4a38-b1b2-a20303e3ea35"/> </disk> </disks>
Hey. it seems that the url that this xml was posted into was the vm's disks, and not /api/templates/ ... checked again in the same environment and it worked. also, make sure your'e posting with HTTPS protocol rather than HTTP.
Verified on vt16.1
This is an automated message. oVirt 3.5.4 has been released on September 3rd 2015 and should include the fix for this BZ. Moving to closed current release.