On 2/3/14, 1:07 PM, "David Nalley" <da...@gnsa.us> wrote:
>> 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) No, it doesn¹t. deployVm with startVm=false just allocates the volume/vm in the DB. Allocators are being invoked only when vm starts for the first time. > >> 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. Our API layer generates error messages based on the caller context. Of course, the detailed message will be returned only to the Root admin while regular user will get the generic message (the way we do now) > >--David
