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

[Itamar Heim]

On 05/16/2012 04:17 PM, Michael Pasternak wrote:
> 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 at redhat.com>
>>>>> To: "Michael Pasternak"<mpastern at redhat.com>
>>>>> Cc: "engine-devel"<engine-devel at ovirt.org>, "Itamar Heim"<iheim at redhat.com>, "Doron Fediuck"<dfediuck at redhat.com>,
>>>>> "Gilad Chaplik"<gchaplik at 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?

two different things:
1. vm name is unique.
2. import vm cannot import an existing vm based on it's uuid (which is 
what this feature is about).

i.e., if i create a vm X, export it, rename X to Y, i will still fail 
importing X without 'cloning' it (the cloning process is about changing 
uuid's of vm, disks, nics)

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