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

On 01/16/2012 01:58 PM, Ayal Baron wrote: > > ----- Original Message ----- >> 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. >>> >>> 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. >> > Just bear in mind that user should still be able to export an > entire template (should be single action to choose export domain > and that's it). > > When importing a template, user should be able to specify per disk > the destination domain. > (default should keep all disks in same domain) > > When creating a VM from template there should still be a default > for each disk, preferably user configurable default (it would be > very annoying to deploy 20 VMs from the template and changing the > default every time). > > Clone VM from template should allow user to choose per disk *any* > storage domain even if it doesn't have a copy of the template > disk. Does this imply that we would copy the template behind the scenes for them or does it mean we are going to let them put the disk in a place where it can't work?

> I'm assuming template versioning would require user to recopy all > the disks, I would add a checkbox to initiate copy to the same > domains as the parent template. If child template has additional > disks - no special treatment should be given (user can later on > copy those disks wherever she chooses)