Open Stack

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?