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
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
star
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
I believe it's a nice idea. A lot of us have experienced the
annoying InsufficientCapacityException in Deploying Virtual Machines, but
we can't tell exactly why just by reading the logs.
If this new API could help us debug this VM deployment process to determine
exactly which resource is lacking,
Great idea, this would certainly reduce vm deployment failures.
VR including RVR if needs to be created, should get included in this check.
Also, can we include ways to check if a VM can be launched in a certain
cluster? The idea is to allow users / admins to be able to launch vm in a
certain
I like the idea. Would the api query the db or the bakends (i.e. hosts,
storage, etc)?
mobile bilingual spell checker used
Op 1 feb. 2014 17:13 schreef "abhisek basu" :
> Great idea, this would certainly reduce vm deployment failures.
>
> VR including RVR if needs to be created, should get incl
answer from CloudStack
storage/host allocators whethere there is enough resources for vm deployment
I like the idea. Would the api query the db or the bakends (i.e. hosts,
storage, etc)?
mobile bilingual spell checker used
Op 1 feb. 2014 17:13 schreef "abhisek basu" :
> Great ide
t;
> Thanks!
> Santhosh
>
> From: Daan Hoogland [daan.hoogl...@gmail.com]
> Sent: Saturday, February 01, 2014 11:24 AM
> To: dev
> Subject: Re: [PROPOSAL] Introduce API returning you an answer from CloudStack
> storage/host allocators whethere there is enough
From: Daan Hoogland [daan.hoogl...@gmail.com]
>> Sent: Saturday, February 01, 2014 11:24 AM
>> To: dev
>> Subject: Re: [PROPOSAL] Introduce API returning you an answer from
>> CloudStack storage/host allocators whethere there is enough resources for vm
>> deployment
>>
\other commands applicable and
return with codes before proceeding further with steps of deploy mentioned.
>>>
>>> Thanks!
>>> Santhosh
>>> ____________
>>> From: Daan Hoogland [daan.hoogl...@gmail.com]
>>> Sent: Satu
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
On Mon, Feb 03, 2014 at 09:09:44AM -0500, David Nalley wrote:
> 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
dstack.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 - a
ge 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 fr
> 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 2/3/14, 1:07 PM, "David Nalley" 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 dep
16 matches
Mail list logo
