----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Itamar Heim" <iheim@redhat.com>, "Omer Frenkel" <ofrenkel@redhat.com> Cc: "Gilad Chaplik" <gchaplik@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "Doron Fediuck" <dfediuck@redhat.com>, "Ori Liel" <oliel@redhat.com> Sent: Wednesday, May 16, 2012 4:17:57 PM Subject: Re: restapi: New params for import VM/Template
On 05/16/2012 04:05 PM, Itamar Heim wrote:
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@redhat.com> To: "Michael Pasternak"<mpastern@redhat.com> Cc: "engine-devel"<engine-devel@ovirt.org>, "Itamar Heim"<iheim@redhat.com>, "Doron Fediuck"<dfediuck@redhat.com>, "Gilad Chaplik"<gchaplik@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
i think it based on name, Omer?
I wrote the backend-side, it is by uuid.
{ 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