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

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