[Engine-devel] the future of template cloning

Tue Jan 17 16:35:14 UTC 2012

On 17/01/12 18:04, Jon Choate wrote:
> On 01/17/2012 10:49 AM, Livnat Peer wrote:
>> On 17/01/12 17:04, Omer Frenkel wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Jon Choate"<jchoate at redhat.com>
>>>> To: engine-devel at ovirt.org
>>>> Sent: Tuesday, January 17, 2012 3:52:34 PM
>>>> Subject: Re: [Engine-devel] the future of template cloning
>>>>
>>>> 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?
>>> fine by me, although i think we should remove the clone template
>>> (actually called copy template),
>>> as i think the copy disk gives a way to do it, with more granularity,
>>> and the user will know exactly what to expect.
>>>
>>
>> We are removing the cloneTemplate and introducing cloneTemplatedisk,
>> following the above discussion does anyone have strong objection for
>> doing this?
>>
> 
> We can't remove cloneTemplate until it is removed from the UI or else we
> will break functionality.  For now we are just going to ensure that it
> works as it always has until the UI is ready to remove it.
> 

If by ensure you mean you are going to do adjustments for the
cloneTemplate code to work then it is not needed.

You can either send a patch to disable/remove this button from the UI
or synchronize your patch with a patch from the UI that removes this button.

I don't like the approach of leaving the code because many times we end
up with a code that is not used and not maintained.

>>> unfortunately, there is another issue,
>>> currently, since template can be fully on a domain or not,
>>> remove template can get list of storage domains to remove the
>>> template from,
>>> and if the list contains all the domain the template is on, the
>>> template is fully deleted from the db,
>>> if its partial, then only the copies of the disks are removed from
>>> the domain.
>>>
>> Worth Noting that we have another REST API gap that we can use in our
>> favor, the delete template from storage domain is not modeled yet and we
>> don't need to support it.
>>
>>> what i suggest is, making it simple:
>>> remove template will remove the template, and all of the disks copies
>>> from all the domains.
>> +1 for that approach.
>>
>>> we will need new removeTemplateDisk command that will remove a disk
>>> from a domain,
>>> as long there is another copy of the disk.
>>> if its the last copy it should fail, as removing the disk from all
>>> the domains will change the template,
>>> which is not a supported flow.
>>>
>>> thoughts?
>> I would implement a single verb - removeDisk, it has optional parameter
>> storage domain.
>> If the storage domain is not specified it is simply removing a disk (for
>> template, VM or floating) if a SD is specified in case there is only one
>> image that represent this disk (the only use case for VMs) we remove the
>> disk (same as no passing no SD except for extra validation) if more than
>> one image is associated with this disk (the image-SD map has more than
>> one entry) then remove the relevant mapping.
>>
>> Note: in case of deleting the disk and there is only one image
>> associated with the disk we should remove the device from the vm_devices
>> table as well.
>>
>> Implementing a single generic verb makes it easier to keep backwards
>> compatibility when the model changes.
>>
>> Livnat
>>
>>
>>
>>>> _______________________________________________
>>>> 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
> 