Send from my iPhone .
On 28 בפבר 2012, at 00:16, Ayal Baron <[email protected]> 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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
