[Engine-devel] the future of template cloning

[Livnat Peer]

On 17/01/12 23:00, Miki Kenneth wrote:
> 
> 
> ----- Original Message -----
>> From: "Ayal Baron" <abaron at redhat.com>
>> To: "Livnat Peer" <lpeer at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Tuesday, January 17, 2012 11:45:33 AM
>> Subject: Re: [Engine-devel] the future of template cloning
>>
>>
>>
>> ----- 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.

> I agree. This is the common use case, all disk resides on the same SD.
> and that is why we need a verb for it.
> However, for more "trick"/special cases we need to support multi domains.
> I also think it would be easier from api perspective to use a single copy verb.

The question is what would we like to be the behavior when the operation
fails, the different approaches are mostly around error flows:

- If the clone template is a single action, the error handling would be
to roll back (if the engine failed copying all the images, the images
that were copied successfully to the destination will be deleted).

- If we use the multiple action approach it means that each image that
was copied successfully will stay there and be presented to the user as
success and for those we failed to copy the user will get an error message.