8:58 p.m.
----- 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.
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)