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

From: "Michael Pasternak" <mpastern(a)redhat.com&gt; To: "Itamar Heim" <iheim(a)redhat.com&gt;, "Omer Frenkel" <ofrenkel(a)redhat.com&gt; Cc: "Gilad Chaplik" <gchaplik(a)redhat.com&gt;, "engine-devel" <engine-devel(a)ovirt.org&gt;, "Doron Fediuck" <dfediuck(a)redhat.com&gt;, "Ori Liel" <oliel(a)redhat.com&gt; 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&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 i think it based on name, Omer?

> >> { >> 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