<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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 user of
    OpenStack APIs and the "cloud provider" may be the same entity. It
    would be really nice if when an application fires up an instance
    that enters the error state, there was an api that could get the
    reason why it failed with as much information as the OpenStack code
    that set the instance state to ERROR had. <br>
    <br>
    If we are concerned that such information is sensitive and a public
    provider might not want to give it all to users, this could be an
    admin-only API. There are many<br>
    variations of how the information is controlled.<br>
    <br>
     -David<br>
    <br>
    If we are concerned that a public provider might not want to give
    some information to users, this could be an admin-only API. <br>
    On 6/29/2012 11:40 AM, Day, Phil wrote:
    <blockquote
cite="mid:C49B6B58853ACD4E96677F24DD9C446C73A29BFAC8@GVW1114EXC.americas.hpqcorp.net"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <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]-->
      <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: 10pt; font-family:
            "Courier New"; color: rgb(31, 73, 125);">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.</span></p>
      </div>
    </blockquote>
    <blockquote
cite="mid:C49B6B58853ACD4E96677F24DD9C446C73A29BFAC8@GVW1114EXC.americas.hpqcorp.net"
      type="cite">
      <div class="WordSection1">
        <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"><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
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
              lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
            lang="EN-US">
            <a class="moz-txt-link-abbreviated" href="mailto:openstack-bounces+philip.day=hp.com@lists.launchpad.net">openstack-bounces+philip.day=hp.com@lists.launchpad.net</a>
            [<a class="moz-txt-link-freetext" href="mailto:openstack-bounces+philip.day=hp.com@lists.launchpad.net">mailto:openstack-bounces+philip.day=hp.com@lists.launchpad.net</a>]
            <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> <a class="moz-txt-link-abbreviated" href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><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
              moz-do-not-send="true" 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" style="width:100.0%" width="100%"
          border="0" cellpadding="0">
          <tbody>
            <tr>
              <td style="width:40.0%;padding:.75pt .75pt .75pt .75pt"
                valign="top" width="40%">
                <p class="MsoNormal"><b><span
style="font-size:7.5pt;font-family:"Arial","sans-serif"">Eoghan
                      Glynn <<a moz-do-not-send="true"
                        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 style="width:59.0%;padding:.75pt .75pt .75pt .75pt"
                valign="top" width="59%">
                <table class="MsoNormalTable" style="width:100.0%"
                  width="100%" border="0" cellpadding="0">
                  <tbody>
                    <tr>
                      <td style="padding:.75pt .75pt .75pt .75pt"
                        valign="top">
                        <p class="MsoNormal" style="text-align:right"
                          align="right"><span
style="font-size:7.5pt;font-family:"Arial","sans-serif"">To</span><o:p></o:p></p>
                      </td>
                      <td style="padding:.75pt .75pt .75pt .75pt"
                        valign="top">
                        <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 style="padding:.75pt .75pt .75pt .75pt"
                        valign="top">
                        <p class="MsoNormal" style="text-align:right"
                          align="right"><span
style="font-size:7.5pt;font-family:"Arial","sans-serif"">cc</span><o:p></o:p></p>
                      </td>
                      <td style="padding:.75pt .75pt .75pt .75pt"
                        valign="top">
                        <p class="MsoNormal"><span
style="font-size:7.5pt;font-family:"Arial","sans-serif""><a
                              moz-do-not-send="true"
                              href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>,
                            Jay Pipes <<a moz-do-not-send="true"
                              href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>></span>
                          <o:p></o:p></p>
                      </td>
                    </tr>
                    <tr>
                      <td style="padding:.75pt .75pt .75pt .75pt"
                        valign="top">
                        <p class="MsoNormal" style="text-align:right"
                          align="right"><span
style="font-size:7.5pt;font-family:"Arial","sans-serif"">Subject</span><o:p></o:p></p>
                      </td>
                      <td style="padding:.75pt .75pt .75pt .75pt"
                        valign="top">
                        <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>
                  </tbody>
                </table>
                <p class="MsoNormal"><o:p> </o:p></p>
                <table class="MsoNormalTable" border="0" cellpadding="0">
                  <tbody>
                    <tr>
                      <td style="padding:.75pt .75pt .75pt .75pt"
                        valign="top"><br>
                      </td>
                      <td style="padding:.75pt .75pt .75pt .75pt"
                        valign="top"><br>
                      </td>
                    </tr>
                  </tbody>
                </table>
              </td>
            </tr>
          </tbody>
        </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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Mailing list: <a class="moz-txt-link-freetext" href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a>
Post to     : <a class="moz-txt-link-abbreviated" href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>
Unsubscribe : <a class="moz-txt-link-freetext" href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a>
More help   : <a class="moz-txt-link-freetext" href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>