Open Stack

Duncan Thomas [mailto:duncan.thomas at gmail.com] on Wednesday, February 04, 2015 8:34 AM wrote:

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

[Rockyg]  In discussions at the summit about assigning error codes, we determined it would be pretty straightforward to build a tool that could be called when a new code was needed and it would both assign an unused code and insert the error summary for the code in the DB it would keep to ensure uniqueness.  If you didn’t provide a summary, it wouldn’t spit out an error code;-)  Simple little tool that could be in oslo, or some cross-project code location.

--Rocky

On 3 February 2015 at 03:24, Sean Dague <sean at dague.net<mailto: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<http://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://OpenStack-dev-request@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/20150205/e5aec4ba/attachment.html>