Open Stack

The downside of numbers rather than camel-case text is that they are less
likely to stick in the memory of regular users. Not a huge think, but a
reduction in usability, I think. On the other hand they might lead to less
guessing about the error with insufficient info, I suppose.

To make the global registry easier, we can just use a per-service prefix,
and then keep the error catalogue in the service code repo, pulling them
into some sort of release periodically

On 3 February 2015 at 03:24, 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
>
>


-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150204/5e450e71/attachment.html>