Send from my iPhone . On 28 בפבר 2012, at 00:16, Ayal Baron <abaron@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel