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(a)redhat.com>
>>>> To: "Michael Pasternak"<mpastern(a)redhat.com>
>>>> Cc: "engine-devel"<engine-devel(a)ovirt.org>, "Itamar
Heim"<iheim(a)redhat.com>, "Doron Fediuck"<dfediuck(a)redhat.com>,
>>>> "Gilad Chaplik"<gchaplik(a)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
>>>>
>>
>>
>