<br><font size=2 face="sans-serif">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 might have happened since
then, erasing any "error message" type of state info.  And
relying on event/error logs is hard since correlating one particular action
with a flood of events is tricky - especially in a multi-user environment
where several actions could be underway at once.  If each action resulted
in a Job URI being returned then the client can check that Job resource
when its convinient for them - and this could be quite useful in both happy
and unhappy situations.  </font>
<br>
<br><font size=2 face="sans-serif">And to be clear, a Job doesn't necessarily
need to be a a full new resource, it could (under the covers) map to a
grouping of event logs entries but the point is that from a client's perspective
they have an easy mechanism (e.g. issue a GET to a single URI) that returns
all of the info needed to determine what happened with one particular operation.</font>
<br><font size=2 face="sans-serif"><br>
thanks<br>
-Doug<br>
______________________________________________________<br>
STSM |  Standards Architect  |  IBM Software Group<br>
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<br>
The more I'm around some people, the more I like my dog.</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Eoghan Glynn <eglynn@redhat.com></b>
</font>
<p><font size=1 face="sans-serif">06/29/2012 06:00 AM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Doug Davis/Raleigh/IBM@IBMUS</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">openstack@lists.launchpad.net, Jay Pipes
<jaypipes@gmail.com></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [Openstack] Nova and asynchronous
instance launching</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2><br>
> Note that I do distinguish between a 'real' async op (where you<br>
> really return little more than a 202) and one that returns a<br>
> skeleton of the resource being created - like instance.create() does<br>
> now.<br>
<br>
So the latter approach at least provides a way to poll on the resource<br>
status, so as to figure out if and when it becomes usable. <br>
<br>
In the happy-path, eventually the instance status transitions to<br>
ACTIVE and away we go.<br>
<br>
However, considering the unhappy-path for a second, is there a place<br>
for surfacing some more context as to why the new instance unexpectedly<br>
went into the ERROR state? <br>
<br>
For example even just an indication that failure occurred in the scheduler<br>
(e.g. resource starvation) or on the target compute node. Is the thought<br>
that such information may be operationally sensitive, or just TMI for a<br>
typical cloud user?<br>
<br>
Cheers,<br>
Eoghan<br>
<br>
</font></tt>
<br>