Bug 1370075 - Create a template via the API ignores the destination storage domain
Summary: Create a template via the API ignores the destination storage domain
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage
Version: 4.0.2.7
Hardware: Unspecified
OS: Unspecified
medium
medium vote
Target Milestone: ovirt-4.1.2
: ---
Assignee: Tal Nisan
QA Contact: Eyal Shenitzky
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-25 09:03 UTC by Raz Tamir
Modified: 2017-12-12 09:22 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-15 15:50:43 UTC
oVirt Team: Storage
ylavi: ovirt-4.1?
ylavi: planning_ack+
ratamir: devel_ack?
ratamir: testing_ack?


Attachments (Terms of Use)
engine and vdsm logs (1.55 MB, application/x-gzip)
2016-08-25 09:03 UTC, Raz Tamir
no flags Details

Description Raz Tamir 2016-08-25 09:03:32 UTC
Created attachment 1193929 [details]
engine and vdsm logs

Description of problem:
Trying to create a template via the API and specifying the destination storage domain for the template's disk, will ignores the specified storage domain and will create the template's disk on the source storage domain which is the VM's disk storage domain from which the template was created.

The REST API command: POST /api/templates

<template>
    <name>test</name>
    <cluster id="2a2c5474-a207-42f0-8d5c-9c671fc99023"/>
    <storage_domain id="e4146ca7-9465-4fed-9ab3-07391953c859"/>
    <vm id="d18197e4-126d-437c-a29a-f4811d6417f8"/>
</template>

From the enving.log:
2016-08-25 11:45:12,648 INFO  [org.ovirt.engine.core.vdsbroker.irsbroker.CopyImageVDSCommand] (default task-4) [ca82b37] START, CopyImageVDSCommand( CopyImageVDSCommandParameters:{runAsync='true', storagePoolId='d06bd8de-ae75-45ce-8d15-7be11dad7e8a', ignoreFailoverLimit='false', storageDomainId='e36cb55f-df9b-410d-b61c-810d21d31ce7', imageGroupId='0522f4e7-74fa-4066-8b34-33a201ed1100', imageId='2b860890-8503-4115-b379-1346ad2a2e0a', dstImageGroupId='3ea19e4c-3339-44a6-91c2-354dd7c28708', vmId='d18197e4-126d-437c-a29a-f4811d6417f8', dstImageId='2339fe60-f1dc-4589-be2a-d903830821cd', imageDescription='{"DiskAlias":"golden_mixed_virtio_template","DiskDescription":"golden_env_mixed_virtio_0_Disk1 (07f46b6)"}', dstStorageDomainId='e36cb55f-df9b-410d-b61c-810d21d31ce7', copyVolumeType='SharedVol', volumeFormat='COW', preallocate='Sparse', postZero='false', force='false'}), log id: 41a5ce6f

dstStorageDomainId='e36cb55f-df9b-410d-b61c-810d21d31ce7' is equal to storageDomainId='e36cb55f-df9b-410d-b61c-810d21d31ce7'
and in the POST body <storage_domain id="e4146ca7-9465-4fed-9ab3-07391953c859"/>

Via the UI this process is working fine



Version-Release number of selected component (if applicable):
ovirt-engine-4.0.2.7-0.1.el7ev.noarch
vdsm-4.18.11-1.el7ev.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create a vm with disk on storage domain A
2. Create a template via REST API of that VM specifying storage_domain='ID' where ID is the ID of storage domain B
3.

Actual results:
The template will create successfully but the template's disk will be created on storage domain A


Expected results:


Additional info:
logs attached - creation of the template at 2016-08-25 11:45:12,648

Comment 1 Allon Mureinik 2016-08-25 09:18:11 UTC
Is this the V3 or V4 API?

Comment 2 Raz Tamir 2016-08-25 09:18:57 UTC
V4 API

Comment 3 Tal Nisan 2016-09-19 12:49:55 UTC
This also occurs in V3 and this is actually the behavior since version 3.1 in which the option to specify a destination storage domain per disk was introduced.

The behavior is that when a storage domain is specified it will be set as destination for all disks ONLY if a disk attachments list was supplied in the request body and in that case it is overriding all storage domain data that is defined for each disk in the list.

With regards to this bug there are two options:

1. Continue ignoring this parameter if a disk attachments list was not supplied with the request (thus closing as NOTABUG)
2. Override all disks destination domain to the storage domain defined in the parameter even if a disk list was not supplied

Aside for that there is another bug which ignores the storage domain defined to each disk attachment in the list in the request and for that another bug will be opened

Comment 4 Yaniv Lavi 2016-09-27 08:10:45 UTC
(In reply to Tal Nisan from comment #3)
> 2. Override all disks destination domain to the storage domain defined in
> the parameter even if a disk list was not supplied
> 

We should use this behavior it makes more sense. 

> Aside for that there is another bug which ignores the storage domain defined
> to each disk attachment in the list in the request and for that another bug
> will be opened

This there is no way to define a target storage then, right?

Comment 5 Yaniv Lavi 2017-03-15 15:50:43 UTC
If this works per disk, then this is good enough unless a user\customer requests to change this.


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