Re: [Engine-devel] the future of template cloning

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"<iheim(a)redhat.com> >>>>> To: "Jon Choate"<jchoate(a)redhat.com> >>>>> Cc: engine-devel(a)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.

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