[Engine-devel] the future of template cloning

[Jon Choate]

On 01/17/2012 07:29 AM, Livnat Peer wrote:
> 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
>>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
I would like this discussion to continue but I need some short-term 
closure since I only have two days to get something into code. He is 
what I am proposing to do:

1) leave clone template as it is. It will try to copy all of the disks 
to the same storage domain.
2) Expose a copy disk command so that the user can select a single disk 
and create a copy of it on another storage domain.

Is everyone ok with starting there and then refining once we can reach 
more of a consensus on what the end product should be?