[Engine-devel] Clone VM from snapshot feature

[Miki Kenneth]

Send from my iPhone .


On 28 בפבר 2012, at 00:16, Ayal Baron <abaron at redhat.com> wrote:

> 
> 
> ----- Original Message -----
>> On 02/27/2012 09:09 PM, Itamar Heim wrote:
>>> On 02/26/2012 05:05 PM, Yair Zaslavsky wrote:
>>>> On 02/26/2012 04:55 PM, Ayal Baron wrote:
>>>>> 
>>>>> 
>>>>> ----- Original Message -----
>>>>>> On 02/26/2012 04:38 PM, Ayal Baron wrote:
>>>>>>> Yair, what about import of VM more than once?
>>>>>> Hi Ayal,
>>>>>> We consider this as a different feature.
>>>>>> Gilad Chaplik is the feature owner.
>>>>>> I can think of some very similar features to this one (not just
>>>>>> import
>>>>>> more than once).
>>>>> 
>>>>> First, I couldn't find a feature page for that.
>>>>> Second, I don't really understand the difference, there are
>>>>> subtle
>>>>> differences in the flow, but it is basically the same.
>>>>> In fact. the only difference I can think of is that it is
>>>>> initiated
>>>>> from import and not from right click on the snapshot...
>>>>> 
>>>>> What other similar features will this *not* cover?
>>>> I can tell you that for current testing until fully integrated
>>>> with
>>>> snapshots modifications, I am testing it on VM which is down.
>>>> Not sure we're interested in this, but here is an example of
>>>> possible
>>>> feature.
>>> 
>>> I think Ayal point/question is similar to mine - why at general
>>> code
>>> level (obviously there are implementation differences) and user
>>> experience wise, the following aren't similar:
>>> [AddVmFromBlank]
>>> AddVmFromTemplate
>>> AddVmFromVm
>>> AddVmFromSnapshot
>>> AddVmFromImportCandidate[1]
>> 
>> Of course there is shared code - for example, in the class diagram I
>> presented for Clone VM from Snapshot, it can clearly be seen that
>> there
>> is code reuse, and there are two paths of "image-creation" (actually,
>> there is of course also a 3rd path of 'createImage' verb) - path for
>> snapshot and path for copyImage - In addition, the code of the
>> "addVmXXXCommand" usually extends AddVmCommand, and of course
>> introduces
>> some changes.
>> In addition , differences may occur at MLA (for example, for
>> clone-vm-from-snapshot, and maybe other future flows I'm considering
>> of
>> adding a new action-group for CloneVm to the code - I'll update the
>> wiki
>> shortly on this), and of course UI-wise.
>> So I hope that now I gave more explanations on where the code is
>> similar
>> and where its different (actually, I would like to point that in my
>> changes, I'm striving to introduce more code-reuse).
> 
> The point is not about code reuse.  It is about the above being the same functionality from the user perspective with a few nuances.  It could actually be implemented in different ways but it's still not multiple features.
> Which also means that user experience should be almost the same in all these scenarios, which is why they should derive from the same point (design wise not implementation wise).
> Today as you mentioned there are 2 different low level commands for achieving the above, but in fact going forward in the new image API, creating a new image whether it is based on an existing image or not and whether it is optimized for performance (collapse) or optimized for space (qcow2 / something else) would be a single command.  Somthing like: createImage size [source] [perf/space]
> 
> So again, code wise you could in fact be invoking different commands (so no code reuse), but the user doesn't care that underlying it is different flows, it is the same operation - creating a new image.
> everything else is a nuance.
I would state it a bit different, the user would like to create new vm (this is the feature) all the rest are different params (flows if you want).
> 
>> 
>> Yair
>> 
>>> 
>>> 
>>> [1] yes, there is a difference if you select more than a single
>>> import
>>> candidate (adding multiple VMs), but that's actually at UI level,
>>> not
>>> backend implementation.
>>> 
>> 
>> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel