Re: [Engine-devel] Clone VM from snapshot feature

----- 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.

> > 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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel