<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><tt><span style='font-size:10.0pt'>>However, considering the unhappy-path for a second, is there a place</span></tt><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>for surfacing some more context as to why the new instance unexpectedly</tt><br><tt>went into the ERROR state? </tt><br><br><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:#1F497D'>I assume the philosophy is that the API has validated the request as far and it can, and returned any meaningful error messages, etc. Anything that fails past that point is something going wrong from the cloud provider and there is nothing the user could have done to avoid the error, so any additional information won’t help them.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:#1F497D'>However on the basis that up-front validation is seldom perfect, and things can change while a request is in flight I think that being able to tell a user that, for example, their request failed because the image was deleted before it could be downloaded would be useful.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:#1F497D'>One approach might be to make the task_state more granular and use that to qualify the error. In general our users have found having the state shown as “vm_state (task_state)” was useful as it shows progress during things like building.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:#1F497D'>Phil<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:#4F81BD'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New";color:#4F81BD'> <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> openstack-bounces+philip.day=hp.com@lists.launchpad.net [mailto:openstack-bounces+philip.day=hp.com@lists.launchpad.net] <b>On Behalf Of </b>Doug Davis<br><b>Sent:</b> 29 June 2012 12:45<br><b>To:</b> Eoghan Glynn<br><b>Cc:</b> openstack@lists.launchpad.net<br><b>Subject:</b> Re: [Openstack] Nova and asynchronous instance launching<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><br><span style='font-size:10.0pt;font-family:"Arial","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. </span> <br><br><span style='font-size:10.0pt;font-family:"Arial","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.</span> <br><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><br>thanks<br>-Doug<br>______________________________________________________<br>STSM | Standards Architect | IBM Software Group<br>(919) 254-6905 | IBM 444-6905 | <a href="mailto:dug@us.ibm.com">dug@us.ibm.com</a><br>The more I'm around some people, the more I like my dog.</span> <br><br><o:p></o:p></p><table class=MsoNormalTable border=0 cellpadding=0 width="100%" style='width:100.0%'><tr><td width="40%" valign=top style='width:40.0%;padding:.75pt .75pt .75pt .75pt'><p class=MsoNormal><b><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>Eoghan Glynn <<a href="mailto:eglynn@redhat.com">eglynn@redhat.com</a>></span></b><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'> </span><o:p></o:p></p><p><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>06/29/2012 06:00 AM</span> <o:p></o:p></p></td><td width="59%" valign=top style='width:59.0%;padding:.75pt .75pt .75pt .75pt'><table class=MsoNormalTable border=0 cellpadding=0 width="100%" style='width:100.0%'><tr><td valign=top style='padding:.75pt .75pt .75pt .75pt'><p class=MsoNormal align=right style='text-align:right'><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>To</span><o:p></o:p></p></td><td valign=top style='padding:.75pt .75pt .75pt .75pt'><p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>Doug Davis/Raleigh/IBM@IBMUS</span> <o:p></o:p></p></td></tr><tr><td valign=top style='padding:.75pt .75pt .75pt .75pt'><p class=MsoNormal align=right style='text-align:right'><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>cc</span><o:p></o:p></p></td><td valign=top style='padding:.75pt .75pt .75pt .75pt'><p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'><a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>></span> <o:p></o:p></p></td></tr><tr><td valign=top style='padding:.75pt .75pt .75pt .75pt'><p class=MsoNormal align=right style='text-align:right'><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>Subject</span><o:p></o:p></p></td><td valign=top style='padding:.75pt .75pt .75pt .75pt'><p class=MsoNormal><span style='font-size:7.5pt;font-family:"Arial","sans-serif"'>Re: [Openstack] Nova and asynchronous instance launching</span><o:p></o:p></p></td></tr></table><p class=MsoNormal><o:p> </o:p></p><table class=MsoNormalTable border=0 cellpadding=0><tr><td valign=top style='padding:.75pt .75pt .75pt .75pt'></td><td valign=top style='padding:.75pt .75pt .75pt .75pt'></td></tr></table></td></tr></table><p class=MsoNormal style='margin-bottom:12.0pt'><br><br><br><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>> Note that I do distinguish between a 'real' async op (where you</tt><br><tt>> really return little more than a 202) and one that returns a</tt><br><tt>> skeleton of the resource being created - like instance.create() does</tt><br><tt>> now.</tt><br><br><tt>So the latter approach at least provides a way to poll on the resource</tt><br><tt>status, so as to figure out if and when it becomes usable. </tt><br><br><tt>In the happy-path, eventually the instance status transitions to</tt><br><tt>ACTIVE and away we go.</tt><br><br><tt>However, considering the unhappy-path for a second, is there a place</tt><br><tt>for surfacing some more context as to why the new instance unexpectedly</tt><br><tt>went into the ERROR state? </tt><br><br><tt>For example even just an indication that failure occurred in the scheduler</tt><br><tt>(e.g. resource starvation) or on the target compute node. Is the thought</tt><br><tt>that such information may be operationally sensitive, or just TMI for a</tt><br><tt>typical cloud user?</tt><br><br><tt>Cheers,</tt><br><tt>Eoghan</tt><br><br></span><o:p></o:p></p></div></body></html>