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

----- Original Message ----- > From: "Ayal Baron" <abaron(a)redhat.com&gt; > To: "Livnat Peer" <lpeer(a)redhat.com&gt; > Cc: engine-devel(a)ovirt.org > Sent: Tuesday, January 17, 2012 11:45:33 AM > Subject: Re: [Engine-devel] the future of template cloning > > > > ----- 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.

I agree. This is the common use case, all disk resides on the same SD. and that is why we need a verb for it. However, for more "trick"/special cases we need to support multi domains. I also think it would be easier from api perspective to use a single copy verb.