Thanks,
> Phil
>
>
>
> -Original Message-
> From: Chris Behrens [mailto:cbehr...@codestud.com]
> Sent: 02 July 2012 00:14
> To: Day, Phil
> Cc: Jay Pipes; Huang Zhiteng; openstack@lists.launchpad.net
> Subject: Re: [Openstack] Nova and asynchronous instance l
Cc: Jay Pipes; Huang Zhiteng; openstack@lists.launchpad.net
Subject: Re: [Openstack] Nova and asynchronous instance launching
On Jul 1, 2012, at 3:04 PM, "Day, Phil" wrote:
> Rather than adding debug statements could we please add additional
> notification events (for example a notification
On Jul 1, 2012, at 3:04 PM, "Day, Phil" wrote:
> Rather than adding debug statements could we please add additional
> notification events (for example a notification event whenever task_state
> changes)
>
This has been in trunk for a month or maybe a little longer.
FYI
- Chris
___
ay=hp@lists.launchpad.net
[mailto:openstack-bounces+philip.day=hp@lists.launchpad.net] On Behalf Of
Jay Pipes
Sent: 29 June 2012 18:47
To: Huang Zhiteng
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Nova and asynchronous instance launching
On 06/29/2012 04:25 AM, Huang Zhiteng wrote:
> Soun
On 06/29/2012 01:50 PM, David Kranz wrote:
> An assumption is being made here that the "user" and "cloud provider"
> are unrelated. But I think there are many projects under development
> where a cloud-based service is being provided on top of an OpenStack
> infrastructure. In that use case, the di
There's only 1 rpc call unless you're running cactus or something. All
schedulers have a loop...not API.
min-count is unfortunately special cased right now to be a single call vs cast,
though. I was going to fix that real soon. Problem is scheduler creating the
DB records vs API in this case
| IBM 444-6905 | d...@us.ibm.com
The more I'm around some people, the more I like my dog.
Jay Pipes
06/29/2012 06:03 PM
To
Doug Davis/Raleigh/IBM@IBMUS
cc
openstack@lists.launchpad.net, Huang Zhiteng
Subject
Re: [Openstack] Nova and asynchronous instance launching
I'm not e
On 06/29/2012 05:45 PM, Doug Davis wrote:
You don't really expect a client (think ec2-like-user) to analyze debug
info do you?
I really think we need a nice consistent way for people to see what's
going on with long-running operations. Debug info isn't that to me.
thanks
-Doug
Also, see:
h
+dug=us.ibm@lists.launchpad.net
06/29/2012 01:46 PM
To
Huang Zhiteng
cc
openstack@lists.launchpad.net
Subject
Re: [Openstack] Nova and asynchronous instance launching
On 06/29/2012 04:25 AM, Huang Zhiteng wrote:
> Sound like a performance is
hiteng
cc
openstack@lists.launchpad.net
Subject
Re: [Openstack] Nova and asynchronous instance launching
On 06/29/2012 04:25 AM, Huang Zhiteng wrote:
> Sound like a performance issue. I think this symptom can be much
> eased if we spend sometime fixing whatever bottleneck causing this
> (slo
ay=hp@lists.launchpad.net
[mailto:openstack-bounces+philip.day=hp@lists.launchpad.net] *On
Behalf Of *Doug Davis
*Sent:* 29 June 2012 12:45
*To:* Eoghan Glynn
*Cc:* openstack@lists.launchpad.net
*Subject:* Re: [Openstack] Nova and asynchronous instance launching
Right - examining the
On 06/29/2012 04:25 AM, Huang Zhiteng wrote:
Sound like a performance issue. I think this symptom can be much
eased if we spend sometime fixing whatever bottleneck causing this
(slow AMQP, scheduler, or network)? Now that Nova API has got
multprocess enabled, we'd move to next bottleneck in lon
oug Davis
Sent: 29 June 2012 12:45
To: Eoghan Glynn
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Nova and asynchronous instance launching
Right - examining the current state isn't a good way to determine what happened
with one particular request. This is exactly one of the
> Right - examining the current state isn't a good way to determine
> what happened with one particular request. This is exactly one of
> the reasons some providers create Jobs for all actions. Checking the
> resource "later" to see why something bad happened is fragile since
> other opertaons mig
sts.launchpad.net, Jay Pipes
Subject
Re: [Openstack] Nova and asynchronous instance launching
> Note that I do distinguish between a 'real' async op (where you
> really return little more than a 202) and one that returns a
> skeleton of the resource being created - like ins
> Note that I do distinguish between a 'real' async op (where you
> really return little more than a 202) and one that returns a
> skeleton of the resource being created - like instance.create() does
> now.
So the latter approach at least provides a way to poll on the resource
status, so as to fi
On Fri, Jun 29, 2012 at 5:19 AM, Devin Carlen wrote:
> On Jun 28, 2012, at 9:01 AM, Jay Pipes wrote:
>
>> On 06/27/2012 06:51 PM, Doug Davis wrote:
>>> Consider the creation of a "Job" type of entity that will be returned
>>> from the original call - probably a 202. Then the client can check the
On Jun 28, 2012, at 9:01 AM, Jay Pipes wrote:
> On 06/27/2012 06:51 PM, Doug Davis wrote:
>> Consider the creation of a "Job" type of entity that will be returned
>> from the original call - probably a 202. Then the client can check the
>> Job to see how things are going.
>> BTW - this pattern ca
Jay Pipes
Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net
06/28/2012 12:01 PM
To
openstack@lists.launchpad.net
cc
Subject
Re: [Openstack] Nova and asynchronous instance launching
On 06/27/2012 06:51 PM, Doug Davis wrote:
> Consider the creation of a "Job" type of en
On 06/27/2012 06:51 PM, Doug Davis wrote:
Consider the creation of a "Job" type of entity that will be returned
from the original call - probably a 202. Then the client can check the
Job to see how things are going.
BTW - this pattern can be used for any async op, not just the launching
of multi
more I like my dog.
Devin Carlen
Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net
06/27/2012 03:53 PM
To
"openstack@lists.launchpad.net (openstack@lists.launchpad.net)"
cc
Subject
[Openstack] Nova and asynchronous instance launching
We filed a blueprint f
We filed a blueprint for this yesterday:
https://blueprints.launchpad.net/nova/+spec/launch-instances-async
"Currently if a user attempts to create a lot of instances with a single API
call (using min_count) the request will hang for a long time while all RPC
calls are completed. For a large nu
22 matches
Mail list logo
