> After reviewing all the suggestions, we should probably do this in the > future: > > 1) Introduce the call reserveCapacityForVirtualMachine. You can execute > the call with "count" parameter to reserve the capacity for "n" vms w/o > actually deploying them on the backend(no actual volume creation on > storage, no vm start on the host).
Doesn't the deployVirtualMachine with startvm=false accomplish most of this? (admittedly there'd be volume creation, and vm start) > 2) Enhance deployVm call with "count" parameter. Before actual vm > deployment, reserveCapacity underlying method should be called to reserve > the capacity for all "n" vms requested in the call. I think you'll find this is a heavily desired functionality. I know folks who have rather simple portals that call deployVM in a for loop to pull this off. > 3) Improve InsufficientCapacity error messages returned when deployVm > fails to return more clear reason for vm deployment failure. I'd be somewhat worried about information leakage even more with ability to use count=n. Imagine me going to $foo_cloud_provider and running this to determine exactly how much capacity is available. I assume (though didn't see it explicitly called out) that quotas would cause a failure in capacity checking as well? If so, that would probably ameliorate any concerns. --David
