Open Stack

It makes sense to me. ERROR means the VM is not ACTIVE

I think we should also consider making any remaining synchronous
operations (like live-migration) into asynchronous operations, using
instance-actions to report any errors.

In terms of a GUI, I have seen something like this work well: Horizon
already has notifications of errors/success as they happen (with
toaster style messages). If the message just fades away, then the
notification can be considered unread, and you can show some kind of
warning or error messages next to the server it relates to as a hint
towards the error if it is unread. If you click on it, it jumps into a
"log" tab that tells you about all your recent messages, tracking what
is read or not. The UI layer could store what messages have been read.

John

On 7 May 2013 19:56, Andrew Laski <andrew.laski at rackspace.com> wrote:
> With the upcoming v3 API, the recorded InstanceActions and failures, and a
> proposal to remove instance faults I think we should figure out how we want
> to handle various failures that can occur and how to present that to a user.
>
> First, I think it's helpful to make a distinction between a failure to
> perform some action, and an instance that is actually in some unusable error
> state.  A failure to set a new password on an instance, or a resize that
> doesn't succeed for some reason but leaves the instance untouched should
> leave the instance in an ACTIVE state.  An instance that fails in the middle
> of a resize and is not running on the source or destination host is in an
> ERROR state.
>
> The v2 API doesn't work this way, but I'd like to introduce this distinction
> into v3.  So that presents a few questions.
>
> Is there a reason not to make this distinction?
>
> From a UX perspective, what is a good way to present that something
> unexpected happened that didn't set the instance to ERROR?  The
> InstanceActions extension makes this data available but there's nothing to
> indicate when someone should look there for data.  This separation does has
> the advantage of being able to indicate that multiple things failed for a
> single request, but it's still not immediately obvious.  I could see
> bundling the last failure of the last request when retrieving an instance
> which would be similar to the current way of presenting failure data.  Or a
> status field indicating success/failure of the latest request and more info
> could be retrieved from InstanceActions.  I would love to hear best
> practices or thoughts around how best to present this data.
>
> The other question I see, is how much can be done before we get to a v2 API
> breaking change?  Specifically things along the line of changing something
> like resize to fail without setting the instance to ERROR.  Would it be
> considered a breaking change to store a failure in InstanceActions but not
> indicate a failure in the v2 API?
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev