[Engine-devel] the future of template cloning

[Livnat Peer]

On 18/01/12 02:22, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
>> 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.
> 
> Which is wrong because multipleRunAction assumes there are no dependencies between the actions.  In the case of copyTemplate the user sees copying all disks as a single operation which should either fail or succeed.  Partial results are not clear and can cause other problems.
> Validations in this case should be on the entire set together, not one by one, etc.
> 

I think that using the multi action approach is the better behavior for
the user.
If the user clone a template with 3 disks and the engine was able to
clone only two out of three (got an error on the third copy), As a user
i would rather get a chance to clone the third one again and not
re-clone the other two (it takes time...).

So my vote goes to multi actions.

>>
>>> 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
>>>>
>>
>>