[Engine-devel] the future of template cloning

Tue Jan 17 12:29:43 UTC 2012

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"<iheim at redhat.com>
>>>>> To: "Jon Choate"<jchoate at redhat.com>
>>>>> Cc: engine-devel at 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 at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>