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

[Itamar Heim]

On 05/16/2012 03:49 PM, Michael Pasternak wrote:
> 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)

please note "vm exists" is based on vm uuid, not on vm name

> {
>    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
>>>
>
>