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

On 05/16/2012 03:26 PM, Gilad Chaplik wrote: > > > Thanks, > Gilad. > > ----- Original Message ----- >> From: "Ori Liel&quot;&lt;oliel(a)redhat.com&gt; >> To: "Michael Pasternak&quot;&lt;mpastern(a)redhat.com&gt; >> Cc: &quot;engine-devel&quot;&lt;engine-devel(a)ovirt.org&gt;, "Itamar Heim&quot;&lt;iheim(a)redhat.com&gt;, "Doron Fediuck&quot;&lt;dfediuck(a)redhat.com&gt;, >> "Gilad Chaplik&quot;&lt;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. 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 >>