[Engine-devel] the future of template cloning

[Livnat Peer]

>>
>> 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.
>>
> 
> You're missing the point, if it's a single action then the canDoAction would validate free space for all disks together and wouldn't copy a single byte before failing.
> 

I think the main point is the roll back behavior as i mentioned earlier,
and less the validation of the canDoAction.


> On the other hand, I do agree that if canDoAction succeeds and then one of the copies fails then you have to rollback which is not nice.
> If you can do an aggregated canDoAction for copying multiple disks using the multipleRunAction (i.e. calculate space needed for *all* disks on each target domain and warn user before starting or fail) and GUI-wise the operation is done on the disks themselves and not on the template then I'm fine with that.
> 

The engine has built-in support for adding shared logic for multiple
actions.
I think it makes sense to add a validation for the storage capacity on
the summary of all storage requests.

I rather get another input on this before going with the shared logic -

If implementing the above behavior it means we are going to fail cloning
all disks if there is not enough space to clone one of them regardless
of the destination storage domain.

For example:

- There are 2 domains each has 10G free space
- There are 3 disks each of them takes 6G
- The engine gets multiple-action command:
	* clone disk1 to domain1
	* clone disk2 to domain1
        * clone disk3 to domain2

Result:
- engine fails all command although we could have cloned disk3.

I am ok with the above scenario just want to make clear what is going to
be the behavior.


> 
> <SNIP>