[Engine-devel] restapi: New params for import VM/Template

[Ori Liel]

>On 05/16/2012 02:49 PM, Ori Liel wrote:
>>> On 05/16/2012 01:16 PM, Gilad Chaplik wrote:
>>>> Hi All,
>>>>
>>>> I am adding the ability to import a VM or a Template to a storage-domain,
>>>> when this VM or Template already exists in the destination storage domain.
>>>> Until now, Backend failed this. Now I want to enable the user to specify
>>>> that he wishes this VM/Template will be created again by a different name,
>>>> i.e - cloned.
>>>>
>>>> [feature page: http://www.ovirt.org/wiki/Features/ImportMoreThanOnce]
>>>>
>>>> I plan to achieve this using a new parameter, but I want to reach an agreement
>>>> about this parameter's name. I thought simply to call it "clone".
>>>>
>>>> Another thing that I'll do in the patch-set is add the currently-missing ability
>>>> to specify whether the snapshots of the VM, which is being imported, will
>>>> be collapsed into a single snapshot (we have this ability in GUI). I am also
>>>> deliberating about the name of this parameter. I thought about
>>>> "collapse_snapshots" (same as in GUI).
>>>>
>>>> Does anyone think "clone" and "collapse_snapshots" are inappropriate and has
>>>
>>> /clone/ already in-use (used to clone vm from template),
>>>
>>> <vm>
>>>  <disks>
>>>    <clone>true|false</clone>
>>> ...,
>>>
>>> you can simply say if imported vm has <name> element, this is import+clone, otherwise import,
>>
>> If in the future we will want to enable overriding a VM's params on import, this will be confusing
>> (because a user might want to import a VM and change it's name - but not clone it if it already exists).
>
>the concept of /import/ is copy vm from sd1 to sd2, then you can change vm meta as needed,

ok

>besides we already using <name> element existence/absence as action 'determinator' in other
>places in api.

It's true, existence of ID/name does determine behaviour elsewhere in the API. In this specific case, 
it feels a bit less intuitive; what do you think about the difference between the following two 
scenarios?  

If user passes clone=true, and this VM doesn't already exist on the destination storage-domain, then
the operation fails - makes direct sense: you wanted to clone, but this VM doesn't already exist. 

If user passes name=VM1, and this VM doesn't already exist on the destination storage-domain, then
the operation fails - a bit strange. The logic is more construed: you supplied a name, therefore you 
meant you want to clone, but this VM doesn't already exist.

>
>>
>>> as about collapse_snapshots, i don't mind, but this should be done in the way <clone> is implemented
>>> in <disks> collection
>>
>> Semantically, a snapshot is a point in time of a VM. It not only associated any more only with the VM's
>> disks; it includes the VM's meta-data as well. For this reason, maybe the parameter collapse_snapshots
>> should not be in <disks> collection (although, technically, the collapse will be done on disks)
>
>obviously i meant <snapshots>, thanks.
>
>>
>>>
>>>
>>>> better suggestions?
>>>>
>>>> Thanks,
>>>> Gilad
>>>
>>>
>>> --
>>>
>>> Michael Pasternak
>>> RedHat, ENG-Virtualization R&D
>
>
>-- 
>
>Michael Pasternak
>RedHat, ENG-Virtualization R&D