Thank you everyone for responding with your concerns and ideas. After analyzing all the input and talking to Alex, I would like to recall the original proposal as:
1) The call doesn't actually do any resource reservation, there is no guarantee that subsequent VM call wouldn't fail if executed some time later. 2) It's not very useful to the check for a SINGLE vm, only to deploy this single vm later. What would make more sense - to check if we can accomodate "n" number of vms, and may be even to reserve the capacity for them. 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). 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. 3) Improve InsufficientCapacity error messages returned when deployVm fails to return more clear reason for vm deployment failure. Let me know what you all think, -Alena. On 2/3/14, 9:55 AM, "Alex Huang" <alex.hu...@citrix.com> wrote: >What's really needed is a reserve API. It would be a big undertaking >though as that concept is not in any of the network and storage plugins. > >--alex > >> -----Original Message----- >> From: David Nalley [mailto:da...@gnsa.us] >> Sent: Monday, February 3, 2014 6:10 AM >> To: dev@cloudstack.apache.org >> Cc: Prachi Damle >> Subject: Re: [PROPOSAL] Introduce API returning you an answer from >> CloudStack storage/host allocators whethere there is enough resources >>for >> vm deployment >> >> Hi Alena: >> >> I am not sure that I see a ton of value in this - and let me explain >>why: >> >> 1. This could potentially be an information disclosure issue - Could I >> potentially see how much storage or other resources are available. >> Does >> >> 2. At any scale things are going to potentially change rapidly, so a >>delay of 5 >> minutes may mean that the content is outdated and no longer valid. >> >> 3. Most importantly deploying a single machine isn't interesting, and >>why >> would I bother checking. (And this also brings up one of the things I >>find >> lacking in the deployVM API call.) What I'd be interested in knowing is >> whether I could deploy 5, 50, or 500 machines. Perhaps adding a count >> parameter to the deployVirtualMachine would help (and the corresponding >> API call to check that resources are >> available.) >> >> --David >> >> On Fri, Jan 31, 2014 at 7:26 PM, Alena Prokharchyk >> <alena.prokharc...@citrix.com> wrote: >> > Currently there is no way to know if there is enough resources for vm >> deployment, before actual deployVm call is made. The sequence is the >> following: >> > >> > 1) Deploy Vm is called >> > 2) DB record is created for the Vm >> > 3) Storage/Host allocators determine whethere there are enough >> resources for vm to be deployed, and return deploy destination to the >>caller >> stack. >> > 4) If allocator returns valid deploy destination, VM gets actually >> created/started on the backend. If allocators don't return the >>destination, >> the DB record created on step 2) gets destroyed, and ResourceAllocation >> exception is thrown back to the API caller. >> > >> > The API I'm going to introduce, would help you to determine whether CS >> physical resources - hosts, storages - can potentially accomodate vm >> deployment (considering template/service/diskOffering) at a given time, >> w/o actually calling the deploy vm. Some admins might find this call >>useful as >> they can always make this check before submitting the deployVm, so in >>case >> it returns NO, you can fail the deployment immediately, w/o calling >> deployVm. Also you can make this call to determine what is lacking for >>certain >> vm deployment, and expand your physical resources accordingly. >> > >> > Please let me know if see any pitfalls in the proposal, as well if >>you see any >> other use cases that can be solved using this API. >> > >> > Prachi, can you please point me to an existing method (or interface) >> defined in Allocators code serving this purpose? >> > >> > Thanks, >> > -Alena.
