Bug 976243 - [rest-api] When creating template, target domain is passed as a source
[rest-api] When creating template, target domain is passed as a source
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi (Show other bugs)
3.2.0
All Linux
unspecified Severity high
: ---
: 3.3.0
Assigned To: Shahar Havivi
Pavel Novotny
virt
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-20 04:00 EDT by Jakub Libosvar
Modified: 2015-09-22 09 EDT (History)
9 users (show)

See Also:
Fixed In Version: is11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
engine vdsm logs (39.76 KB, application/gzip)
2013-06-20 04:00 EDT, Jakub Libosvar
no flags Details

  None (edit)
Description Jakub Libosvar 2013-06-20 04:00:00 EDT
Created attachment 763312 [details]
engine vdsm logs

Description of problem:
When I have two storage domains (SD0 and SD1) and want to create a template on SD1, while source image is on SD0, it fails because target domain (SD1) is passed as a source - i.e. SD1 is passed instead of SD0

Version-Release number of selected component (if applicable):
rhevm-3.2.1-0.31.el6ev.noarch


How reproducible:
Always

Steps to Reproduce:
1. Have two storage domains, VM with a disk on SD0
2. Via API create a template on SD1

Actual results:
GetImageInfoVDSCommand fails due to wrong SD uuid:

GetImageInfoVDSCommand( storagePoolId = a86b5970-7340-4808-96e0-0f0f9c3aaa10, ignoreFailoverLimit = false, compatabilityVersion = null, storageDomainId = b58d59a4-c5ba-4ea9-8dff-29685175cc59, imageGroupId = ecde57a6-e7fa-475a-97c0-24e0738a9707, imageId = 968de0cf-8051-4797-84bd-a1c6e34b1a65), log id: 43658fe7


Expected results:
Same as webadmin does:

GetImageInfoVDSCommand( storagePoolId = a86b5970-7340-4808-96e0-0f0f9c3aaa10, ignoreFailoverLimit = false, compatabilityVersion = null, storageDomainId = 6a083563-0483-46be-8ef0-ce7d5bce4e8f, imageGroupId = ecde57a6-e7fa-475a-97c0-24e0738a9707, imageId = 968de0cf-8051-4797-84bd-a1c6e34b1a65), log id: 6fbce0df


Additional info:
Logs are attached
Body sent to /api/templates:
<template>
    <name>test_templ</name>
    <vm id="3f011275-4cab-4d56-b88d-936eef779e5c"/>
    <cluster id="be951814-2c61-48d0-80e6-1b6cdb8ac4f4"/>
    <storage_domain id="b58d59a4-c5ba-4ea9-8dff-29685175cc59"/>
</template>
Comment 1 Shahar Havivi 2013-08-08 07:00:00 EDT
It's looks like a regression from the following fix:
http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=083eb0820b88d40f40f19006f97cfc580b84d4a6

The fix in this patch is overriding the source image domain with the destination domain (and as long as they the same we didn't have any problem).
Patch:
http://gerrit.ovirt.org/#/c/17827/

Jakub,
This patch will not fix your problem,
The reason that you have a different results in the UI and the API is that you need to set the API disks.

By doing so the API will build the diskInfoDestinationMap which you get for free in the UI.
This suppose to work for you without applying the patch.
Comment 3 Pavel Novotny 2013-09-27 12:43:09 EDT
Verified in rhevm-3.3.0-0.23.master.el6ev (is16).

Creating a VM template via API with a request body described in comment#0 is now successful.
But as was explained in comment#1, tempate disk(s) will be created on the original storage domain (refereced as SD0 in the reproducer). In other words, the <storage_domain> element in the request body does not affect the target location of template disks.
Comment 4 Itamar Heim 2014-01-21 17:24:02 EST
Closing - RHEV 3.3 Released
Comment 5 Itamar Heim 2014-01-21 17:25:04 EST
Closing - RHEV 3.3 Released
Comment 6 Itamar Heim 2014-01-21 17:28:38 EST
Closing - RHEV 3.3 Released

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