Open Stack

Instance faults gets populated when there's an error - most details are
only visible to admins to prevent too much information about the network
from leaking - but if its something a user can fix, the details are
displayed.  For example, setting a password that is too weak for a windows
box, or choosing an image that disappears between create time and build
time (or in my proposal doesn't exist at all).  There are a few other
cases too, and we could easily add more.

That said, our error handling needs help - theres no way to clear an error
if its a non-important one.  For example if it was just a password, that
doesn't matter that much, most likely, setting the password again should
be fine.  There's also no way to see historical errors, or there are even
some cases where it might make sense to show an error, and have the server
be set back to active, and there is no way to do that.  I'm thinking in
the case of a failed resize, if there is an error the most likely desired
state is to have the old server up and running, but with information about
why the resize failed.

Gabe

On 6/8/12 6:13 AM, "Thomas, Duncan" <duncan.thomas at hp.com> wrote:

>The weakness of all of our current async calls (e.g. nova boot) is that
>there is no route to get the details of what failed... when my sever
>comes up in 'error', I'd really like to know why... is it a system error?
>Broken image? Temporary glitch? There doesn't seem to be a channel for
>this kind of information...
>
>-- 
>Duncan Thomas
>HP Cloud Services, Galway
>
>
>> -----Original Message-----
>> From: openstack-bounces+duncan.thomas=hp.com at lists.launchpad.net
>> [mailto:openstack-bounces+duncan.thomas=hp.com at lists.launchpad.net] On
>> Behalf Of Gabe Westmaas
>> Sent: 08 June 2012 06:01
>> To: openstack at lists.launchpad.net
>> Subject: [Openstack] [nova][glance] making nova api more asynchronous
>> 
>> Hey all,
>> 
>> I was looking through some of the api calls, in particular creating a
>> server on the openstack api.  I'm not too excited by how long it takes,
>> and was wondering what people think about making it more asynchronous.
>> Basically, wondering if making it so that the POST to the nova API
>> doesn't
>> actually check to make sure we have a valid image, but instead just
>> assume
>> the user knew what they were doing and pass the image down is something
>> that people buy.  If the image is invalid (doesn't exist, no permission
>> to
>> use that image, flavor size doesn't match the minimum requirements of
>> the
>> image) then we would set the server to error and be done.
>> 
>> There is an obvious drawback: losing the ability to fail fast.  I think
>> we
>> need to look at embracing the overall asynchronous nature of the API as
>> much as possible, and rely on client side tools to do upfront
>> validation
>> where appropriate - nova client would already prevent this from
>> happening
>> on a nonexistent image, for example.
>> 
>> The API spec doesn't specify anything one way or the other about this -
>> so
>> another route is to make this a configuration option.
>> 
>> By the way, I don't want this to be construed in any way, shape or form
>> as
>> me not wanting to improve the performance of glance.  Of course we want
>> that, but we also know that any additional latency hurts performance.
>> 
>> Thoughts? Are the benefits of fail fast out-weighing our performance
>> needs?
>> 
>> 
>> Gabe
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp