Zhiteng; openstack@lists.launchpad.net
Subject: Re: [Openstack] Nova and asynchronous instance launching
On Jul 1, 2012, at 3:04 PM, Day, Phil philip@hp.com wrote:
Rather than adding debug statements could we please add additional
notification events (for example a notification
Subject: Re: [Openstack] Nova and asynchronous instance launching
On Jul 1, 2012, at 3:04 PM, Day, Phil philip@hp.com wrote:
Rather than adding debug statements could we please add additional
notification events (for example a notification event whenever task_state
changes)
This has
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 direct
@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:
Sound like
On Jul 1, 2012, at 3:04 PM, Day, Phil philip@hp.com 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
On Fri, Jun 29, 2012 at 5:19 AM, Devin Carlen de...@openstack.org 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
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
...@gmail.com
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 instance.create() does
now.
So
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 reasons some providers
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
+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 current state isn't a good way to determine what
happened
...@gmail.com
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
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:
-6905 | d...@us.ibm.com
The more I'm around some people, the more I like my dog.
Jay Pipes jaypi...@gmail.com
06/29/2012 06:03 PM
To
Doug Davis/Raleigh/IBM@IBMUS
cc
openstack@lists.launchpad.net, Huang Zhiteng winsto...@gmail.com
Subject
Re: [Openstack] Nova and asynchronous instance launching
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
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
...@gmail.com
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 entity
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 can be used
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
dog.
Devin Carlen de...@openstack.org
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)
openstack@lists.launchpad.net
cc
Subject
[Openstack] Nova and asynchronous instance launching
We filed
20 matches
Mail list logo
