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

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&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) 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 >>> > >