3:44 p.m.
On 05/16/2012 02:49 PM, Ori Liel wrote:
>> 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),
>>
>> <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).
the concept of /import/ is copy vm from sd1 to sd2, then you can change vm meta as needed,
ok
besides we already using <name> element existence/absence as
action 'determinator' in other
places in api.
It's true, existence of ID/name does determine behaviour elsewhere in the API. In this
specific case,
it feels a bit less intuitive; what do you think about the difference between the
following two
scenarios?
If user passes clone=true, and this VM doesn't already exist on the destination
storage-domain, then
the operation fails - makes direct sense: you wanted to clone, but this VM doesn't
already exist.
If user passes name=VM1, and this VM doesn't already exist on the destination
storage-domain, then
the operation fails - a bit strange. The logic is more construed: you supplied a name,
therefore you
meant you want to clone, but this VM doesn't already exist.
>
>> 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)
obviously i meant <snapshots>, thanks.
>
>>
>>
>>> better suggestions?
>>>
>>> Thanks,
>>> Gilad
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
--
Michael Pasternak
RedHat, ENG-Virtualization R&D