Duncan Thomas [mailto:duncan.tho...@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 


On 3 February 2015 at 03:24, Sean Dague <s...@dague.net<mailto:s...@dague.net>> 
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 Dague

OpenStack Development Mailing List (not for usage questions)

Duncan Thomas
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to