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

From: "Jon Choate" <jchoate(a)redhat.com&gt; To: engine-devel(a)ovirt.org Sent: Tuesday, January 17, 2012 3:52:34 PM Subject: Re: [Engine-devel] the future of template cloning On 01/17/2012 07:29 AM, Livnat Peer wrote: > 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&quot;&lt;iheim(a)redhat.com&gt; >>>>>> To: "Jon Choate&quot;&lt;jchoate(a)redhat.com&gt; >>>>>> 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 >>> > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel I would like this discussion to continue but I need some short-term closure since I only have two days to get something into code. He is what I am proposing to do: 1) leave clone template as it is. It will try to copy all of the disks to the same storage domain. 2) Expose a copy disk command so that the user can select a single disk and create a copy of it on another storage domain. Is everyone ok with starting there and then refining once we can reach more of a consensus on what the end product should be?

_______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel