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>