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

[Michael Pasternak]

On 05/16/2012 03:26 PM, Gilad Chaplik wrote:
> 
> 
> Thanks, 
> Gilad.
> 
> ----- Original Message -----
>> From: "Ori Liel" <oliel at redhat.com>
>> To: "Michael Pasternak" <mpastern at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Itamar Heim" <iheim at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>,
>> "Gilad Chaplik" <gchaplik at redhat.com>
>> Sent: Wednesday, May 16, 2012 2:49:17 PM
>> Subject: Re: restapi: New params for import VM/Template
>>
>>> 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),
> 
> clone here has a different context, clone VM vs. clone disks.

having two clone elements in vm will be confusing.

-1

> 
>>>
>>> <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).
> 
> +1, cloning a vm and changing the vm's metadata (i.e vm's name) should not be inter-dependent.

how exactly this is contradict changing metadata on the fly?,
exactly on opposite - it works perfectly well for your use-case:

BE logic:
--------

if (local <storage>) has vm named as on remote <storage> (export.domain)
{
  if PARAMS <name> != remote <name> (export.domain)
  {
    copy + rename
  } else {
    error
  }
} else {
  if PARAMS <name> != remote <name> (export.domain)
  {
    copy + rename
  } else {
    copy
  }
}

> 
>>
>>> 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)
> 
> +1, I think the collapse_snapshots should be in the vm context (snapshots is under vm).

i meant <snapshots>, see my other email on this.

> 
> Other than that, currently, if you want to clone a vm, it must be 'collapsed snapshots', so
> the flow to clone a vm (with your suggestion) will be:
> 
> <action>
>     <vm>
>         <name>new_vm</..>
>         <disks>
>             <collapse_snapshot>true</..> 
>         </..>
>     </..>
>     <clone>true</..>
> </..>
> 
> where collapse_snapshot should be superior to clone, this structure is a bit confusing.
> 
>>
>>>
>>>
>>>> better suggestions?
>>>>
>>>> Thanks,
>>>> Gilad
>>>
>>>
>>> --
>>>
>>> Michael Pasternak
>>> RedHat, ENG-Virtualization R&D
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D