On 02/12/2015 09:59 PM, Robert Collins wrote:
On 5 February 2015 at 13:20, Rochelle Grober <rochelle.gro...@huawei.com> wrote:
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 location.
Apropos of logging, has https://tools.ietf.org/html/rfc5424 been
considered? Combined with https://tools.ietf.org/html/rfc5426 we'd
have a standards based (and thus already supported by logging and
analysis tools) framework. aka, we seem to be on the verge of
inventing a thing thats already been invented.
In what way are either of the above RFCs guidance to our conversation
about how to properly codify error codes in our HTTP APIs?
Best,
-jay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
