On 18/01/12 02:22, Ayal Baron wrote: > > > ----- Original Message ----- >> On 17/01/12 11:45, Ayal Baron wrote: >>> >>> >>> ----- Original Message ----- >>>> On 17/01/12 10:46, Itamar Heim wrote: >>>>> On 01/17/2012 10:32 AM, Omer Frenkel wrote: >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Itamar Heim"<ih...@redhat.com> >>>>>>> To: "Jon Choate"<jcho...@redhat.com> >>>>>>> Cc: engine-devel@ovirt.org >>>>>>> Sent: Monday, January 16, 2012 7:26:24 PM >>>>>>> Subject: Re: [Engine-devel] the future of template cloning >>>>>>> >>>>>>> On 01/16/2012 06:16 PM, Jon Choate wrote: >>>>>>>> On 01/16/2012 10:58 AM, Itamar Heim wrote: >>>>>>>>> On 01/16/2012 05:46 PM, Jon Choate wrote: >>>>>>>>>> On 01/16/2012 09:46 AM, Livnat Peer wrote: >>>>>>>>>>> On 12/01/12 22:45, Ayal Baron wrote: >>>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>> We are going to be able to store the disks for a template >>>>>>>>>>>>> on >>>>>>>>>>>>> different storage domains due to the multiple storage >>>>>>>>>>>>> domain >>>>>>>>>>>>> feature. Cloning a template will still be possible, but >>>>>>>>>>>>> will >>>>>>>>>>>>> it >>>>>>>>>>>>> provide any value? Thoughts? >>>>>>>>>>>> I see no relation between the two options. >>>>>>>>>>>> >>>>>>>>>>>> Scenario 1: I can create a VM with a single disk and >>>>>>>>>>>> create >>>>>>>>>>>> a >>>>>>>>>>>> template from it. >>>>>>>>>>>> I would still want to be able to clone the template in >>>>>>>>>>>> order >>>>>>>>>>>> to >>>>>>>>>>>> provision VMs from it on different domains. >>>>>>>>>>>> >>>>>>>>>>>> Scenario 2: same thing with multiple disks on same domain. >>>>>>>>>>>> >>>>>>>>>>>> Scenario 3: I have a template with 2 disks on 2 different >>>>>>>>>>>> domains >>>>>>>>>>>> (domain A and domain B) and I want to have another copy of >>>>>>>>>>>> the >>>>>>>>>>>> template on domain C and domain D >>>>>>>>>>>> >>>>>>>>>>> Hi Jon, >>>>>>>>>>> >>>>>>>>>>> After talking to Michael Pasternak it seems that we did not >>>>>>>>>>> implemented >>>>>>>>>>> copyTemplate in the REST API, it seems to be a gap that we >>>>>>>>>>> have. >>>>>>>>>>> >>>>>>>>>>> This gap is playing in our favor, we can remove the >>>>>>>>>>> copyTemplate >>>>>>>>>>> verb >>>>>>>>>>> and introduce copyDisk verb. >>>>>>>>>>> >>>>>>>>>>> The template disks can be copied to another SD. >>>>>>>>>>> When creating a VM from template the user can choose per >>>>>>>>>>> disk >>>>>>>>>>> the >>>>>>>>>>> destination SD (only SD with the disks are eligible >>>>>>>>>>> candidates). >>>>>>>>>> wait, when creating a VM from a template, the user won't get >>>>>>>>>> a >>>>>>>>>> choice >>>>>>>>>> will they? Won't the VM disks have to go on the same storage >>>>>>>>>> domain as >>>>>>>>>> the template disks they were created from? >>>>>>>>> >>>>>>>>> yes, but the template disks can be copied to multiple storage >>>>>>>>> domains, >>>>>>>>> so the user can choose for the VM/disk which storage domain >>>>>>>>> to >>>>>>>>> create >>>>>>>>> them from (per storage domains that have copies of that disk) >>>>>>>> OH! I totally misunderstood. So what you are saying is that a >>>>>>>> template >>>>>>>> can have N number of copies of the same disk each on a >>>>>>>> different >>>>>>>> storage >>>>>>>> domain. I had thought that if you wanted that type of >>>>>>>> situation >>>>>>>> you >>>>>>>> would have multiple copies of the template itself too. >>>>>> >>>>>> yes, one copy of disk per domain though. >>>>>> >>>>>>>> >>>>>>>> Just to be clear, does this mean that the plan is to phase out >>>>>>>> the >>>>>>>> current clone template command and instead implementing a >>>>>>>> clone >>>>>>>> disk >>>>>>>> command so that a template can duplicate its disks >>>>>>>> individually? >>>>>>> >>>>>>> pretty much, yes. >>>>>>> though i'd imagine 'clone template' would still be useful to >>>>>>> have >>>>>>> for >>>>>>> the user. not sure if it implies core should expose it as well >>>>>>> to >>>>>>> allow >>>>>>> easier usage at UI level for such a task. >>>>>> >>>>>> we can leave it untouched - means copyTemplate get 1 destination >>>>>> domain, and copies all disks to it, >>>>>> but i think it will be unusable (and problematic - what if one >>>>>> of >>>>>> the >>>>>> disks already exists on the destination?), >>>>> >>>>> then don't copy it, it is already there >>>>> >>>> >>>> I agree with Omer, there is no reason to support copy template, if >>>> the >>>> user wants to clone all the disks he can use multiple actions, we >>>> don't >>>> need a specific verb for this. >>> >>> Reason or lack of depends on the common usage. >>> If we assume that normally all disks of a template would reside on >>> the same domain then it makes sense to have a verb to copy the >>> template in its entirety and not burden the user. >>> The general recommendation should be to use a single storage >>> domain, so I think there is room for such a verb. >>> >> >> >>>> If the UI chooses to expose such operation it will use the >>>> multipleRunAction API which makes it easier to expose to the user >>>> partial success, we could clone disk A and Disk B but Disk C >>>> failed >>>> etc. >>> >>> The multipleRunAction is for user marking multiple objects in GUI >>> and running an action on all of these objects. >> >> Exactly, choosing the disks to copy to the storage domain. > > Which is wrong because multipleRunAction assumes there are no dependencies > between the actions. In the case of copyTemplate the user sees copying all > disks as a single operation which should either fail or succeed. Partial > results are not clear and can cause other problems. > Validations in this case should be on the entire set together, not one by > one, etc. >
I think that using the multi action approach is the better behavior for the user. If the user clone a template with 3 disks and the engine was able to clone only two out of three (got an error on the third copy), As a user i would rather get a chance to clone the third one again and not re-clone the other two (it takes time...). So my vote goes to multi actions. >> >>> Here however, the action the user wants is to copy 1 object (the >>> template) which has sub objects and it should run as a single >>> action. >> >> We are not cloning the template itself we are only cloning the >> template >> disks. >> >> >>> For example, if there is enough space on the target domain for 2/4 >>> disks then using multipleRunAction would result in 2 disks being >>> copied and 2 failing. >> >>> If however it is a single action then the free space test would >>> fail the entire action and user would be able to choose if he >>> wants to copy just 2. >>> Note that in this case, actually performing the copy of the 2 disks >>> is detrimental as it can negatively affect VMs on this domain. >>> >>>> >>>> >>>> >>>>>> what the user really wants is to specify which disks to copy >>>>>> and destination per disk, and i don't see a reason to create a >>>>>> backend >>>>>> command to do it >>>>>> >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel@ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel@ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel@ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >> >> _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel