On 17/01/12 18:04, Jon Choate wrote: > On 01/17/2012 10:49 AM, Livnat Peer wrote: >> On 17/01/12 17:04, Omer Frenkel wrote: >>> >>> ----- Original Message ----- >>>> From: "Jon Choate"<jcho...@redhat.com> >>>> To: engine-devel@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"<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. >>>>> >>>>>> 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 >>>> 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. >>> >> >> We are removing the cloneTemplate and introducing cloneTemplatedisk, >> following the above discussion does anyone have strong objection for >> doing this? >> > > We can't remove cloneTemplate until it is removed from the UI or else we > will break functionality. For now we are just going to ensure that it > works as it always has until the UI is ready to remove it. >
If by ensure you mean you are going to do adjustments for the cloneTemplate code to work then it is not needed. You can either send a patch to disable/remove this button from the UI or synchronize your patch with a patch from the UI that removes this button. I don't like the approach of leaving the code because many times we end up with a code that is not used and not maintained. >>> 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. >>> >> Worth Noting that we have another REST API gap that we can use in our >> favor, the delete template from storage domain is not modeled yet and we >> don't need to support it. >> >>> what i suggest is, making it simple: >>> remove template will remove the template, and all of the disks copies >>> from all the domains. >> +1 for that approach. >> >>> 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? >> I would implement a single verb - removeDisk, it has optional parameter >> storage domain. >> If the storage domain is not specified it is simply removing a disk (for >> template, VM or floating) if a SD is specified in case there is only one >> image that represent this disk (the only use case for VMs) we remove the >> disk (same as no passing no SD except for extra validation) if more than >> one image is associated with this disk (the image-SD map has more than >> one entry) then remove the relevant mapping. >> >> Note: in case of deleting the disk and there is only one image >> associated with the disk we should remove the device from the vm_devices >> table as well. >> >> Implementing a single generic verb makes it easier to keep backwards >> compatibility when the model changes. >> >> Livnat >> >> >> >>>> _______________________________________________ >>>> 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