----- Original Message ----- > > > ----- Original Message ----- > > From: "Jon Choate" <[email protected]> > > To: [email protected] > > 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"<[email protected]> > > >>>>>> To: "Jon Choate"<[email protected]> > > >>>>>> Cc: [email protected] > > >>>>>> 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 > > >>>>>> [email protected] > > >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >>>>>> > > >>>> _______________________________________________ > > >>>> 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 > > >>> > > > _______________________________________________ > > > Engine-devel mailing list > > > [email protected] > > > 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? > > fine by me, although i think we should remove the clone template > (actually called copy template), > as i think the copy disk gives a way to do it, with more granularity, > and the user will know exactly what to expect. > > unfortunately, there is another issue, > currently, since template can be fully on a domain or not, > remove template can get list of storage domains to remove the > template from, > and if the list contains all the domain the template is on, the > template is fully deleted from the db, > if its partial, then only the copies of the disks are removed from > the domain. > > what i suggest is, making it simple: > remove template will remove the template, and all of the disks copies > from all the domains. > we will need new removeTemplateDisk command that will remove a disk > from a domain, > as long there is another copy of the disk. > if its the last copy it should fail, as removing the disk from all > the domains will change the template, > which is not a supported flow. > > thoughts?
This of course needs to be supported in clients, but how exactly will the user keep track of where each disk of the template resides? > > > _______________________________________________ > > 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 > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
