3:26 p.m.
Thanks,
Gilad.
----- Original Message -----
From: "Ori Liel" <oliel(a)redhat.com>
To: "Michael Pasternak" <mpastern(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Itamar Heim"
<iheim(a)redhat.com>, "Doron Fediuck" <dfediuck(a)redhat.com>,
"Gilad Chaplik" <gchaplik(a)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.
>
><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.
>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).
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