Open Stack

On 01/29/2015 12:41 PM, Sean Dague wrote:
> Correct. This actually came up at the Nova mid cycle in a side
> conversation with Ironic and Neutron folks.
>
> HTTP error codes are not sufficiently granular to describe what happens
> when a REST service goes wrong, especially if it goes wrong in a way
> that would let the client do something other than blindly try the same
> request, or fail.
>
> Having a standard json error payload would be really nice.
>
> {
>       fault: ComputeFeatureUnsupportedOnInstanceType,
>       messsage: "This compute feature is not supported on this kind of
> instance type. If you need this feature please use a different instance
> type. See your cloud provider for options."
> }
>
> That would let us surface more specific errors.
<snip>
>
> Standardization here from the API WG would be really great.

What about having a separate HTTP header that indicates the "OpenStack 
Error Code", along with a generated URI for finding more information 
about the error?

Something like:

X-OpenStack-Error-Code: 1234
X-OpenStack-Error-Help-URI: http://errors.openstack.org/1234

That way is completely backwards compatible (since we wouldn't be 
changing response payloads) and we could handle i18n entirely via the 
HTTP help service running on errors.openstack.org.

Best,
-jay