Open Stack

Agree with Sean. A short error name in response body would be better for
applications who consume OpenStack. To my understand, the
X-OpenStack-Error-Help-URI proposed by jpipes will be a uri to error
resolution method. Usually, a consumer application needn't to load its
content.
On Feb 3, 2015 9:28 AM, "Sean Dague" <sean at dague.net> wrote:

> On 02/02/2015 05:35 PM, Jay Pipes wrote:
> > 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.
>
> That could definitely be implemented in the short term, but if we're
> talking about API WG long term evolution, I'm not sure why a standard
> error payload body wouldn't be better.
>
> The if we are going to having global codes that are just numbers, we'll
> also need a global naming registry. Which isn't a bad thing, just
> someone will need to allocate the numbers in a separate global repo
> across all projects.
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150203/ee0c2ba6/attachment.html>