How deep into dependencies would this go? For example, if a new router VM was required would that also be checked?
A chunk of the race conditions and state change issues should be resolvable with ticket reservation system logic, but I'd be concerned the required locks could create problems during infrastructure failures and with HA enabled. We ran into a ton of these types of problems implementing the placement logic in XenServer's workload balancing with HA enabled. On Sat, Feb 1, 2014 at 12:10 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > I like the idea in principal. We should fail as fast as is practical. > > I wonder, are you just checking if the resources are available? If so, it's > still possible for deployVM to fail even if this check said all was good > because the state of the system could change before the actual deployVM is > started. > > > On Fri, Jan 31, 2014 at 7:20 PM, Madan Ganesh Velayudham < > madangan...@me.com > > wrote: > > > Makes lot of sense. Would the same API allow the caller just to check > (not > > actually proceed to create) whether resources are present for a > particular > > payload? This may be useful for the client who want to proactively check > > and avoid returning failure. > > > > Are there any race condition possibilities when multiple requests are > > received? > > ---- > > > > Madan Ganesh Velayudham P.M.P, C.S.M., > > madangan...@me.com > > > > > > > > > > On 01-Feb-2014, at 5:56 am, 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. > > > > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *(tm)* >
