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"<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)
>
> 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
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
