cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yitao Jiang <willier...@gmail.com>
Subject Re: [PROPOSAL] Introduce API returning you an answer from CloudStack storage/host allocators whethere there is enough resources for vm deployment
Date Mon, 03 Feb 2014 12:50:12 GMT
Great idea.i supposed an api could return the remained resources, and then
deciding which host,both storage and compute, to deploy vm.

Koushik Das <koushik.das@citrix.com>于2014年2月3日星期一写道:
> As I understand this is a best-effort approach. Even if the proposed API
returns YES, deployment may still fail. I personally feel that it is better
to improve the deployVM API itself to return accurate error message rather
than having multiple API calls. If the deployvm call call fails, it will
clearly indicate reason for failure so appropriate action can be taken.
>
> -Koushik
>
> On 03-Feb-2014, at 12:35 PM, Rajani Karuturi <Rajani.Karuturi@citrix.com>
wrote:
>
>> I agree with Santhosh. Returning appropriate error codes might be enough.
>>
>> Thanks,
>> ~Rajani
>>
>>
>>
>> On 02-Feb-2014, at 11:17 pm, Santhosh Edukulla <
santhosh.edukulla@citrix.com> wrote:
>>
>>> Just a note:
>>>
>>> Instead of making two separate api calls one to check and then for
deploy, may be it can be part of deploy only and check these conditions for
resources\any other information and return appropriate codes? This check
can be called firsthand as part of deploy\other commands applicable and
return with codes before proceeding further with steps of deploy mentioned.
>>>
>>> Thanks!
>>> Santhosh
>>> ________________________________________
>>> From: Daan Hoogland [daan.hoogland@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
>>>
>>> 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" <abhisekbasu@msn.com>:
>>>
>>>> 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 cluster, but that might be the next functionality.
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On 1 Feb 2014, at 8:50 pm, "Ryan Lei" <ryanlei@cht.com.tw> wrote:
>>>>>
>>>>> 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, or probably other internal reasons
>>>> that
>>>>> cause this InsufficientCapacityException, it would be very helpful!
>>>>>
>>>>>
>>>>
-------------------------------------------------------------------------------------------
>>>>> Yu-Heng (Ryan) Lei, Associate Researcher
>>>>> Cloud Computing Dept, Chunghwa Telecom Labs
>>>>> ryanlei@cht.com.tw or ryanlei750328@gmail.com
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Feb 1, 2014 at 8:26 AM, Alena Prokharchyk <
>>>>> Alena.Prokharchyk@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.
>>>>

-- 

Thanks,

Yitao

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message