On 05/16/2012 03:26 PM, Gilad Chaplik wrote:
>
>
> Thanks,
> Gilad.
>
> ----- Original Message -----
>> From: "Ori Liel" <ol...@redhat.com>
>> To: "Michael Pasternak" <mpast...@redhat.com>
>> Cc: "engine-devel" <engine-devel@ovirt.org>, "Itamar Heim"
>> <ih...@redhat.com>, "Doron Fediuck" <dfedi...@redhat.com>,
>> "Gilad Chaplik" <gchap...@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)
{
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
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
