Open Stack

On 02/12/2015 09:59 PM, Robert Collins wrote:
> On 5 February 2015 at 13:20, Rochelle Grober <rochelle.grober at huawei.com> wrote:
>> 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.
>
> 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