<p dir="ltr">Argh. Wrong thread. Sorry. I was aiming for one about logging :(</p>
<div class="gmail_quote">On 14 Feb 2015 01:48, "Jay Pipes" <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/12/2015 09:59 PM, Robert Collins wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 5 February 2015 at 13:20, Rochelle Grober <<a href="mailto:rochelle.grober@huawei.com" target="_blank">rochelle.grober@huawei.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Duncan Thomas [mailto:<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.<u></u>com</a>] on Wednesday, February 04,<br>
2015 8:34 AM wrote:<br>
<br>
<br>
<br>
The downside of numbers rather than camel-case text is that they are less<br>
likely to stick in the memory of regular users. Not a huge think, but a<br>
reduction in usability, I think. On the other hand they might lead to less<br>
guessing about the error with insufficient info, I suppose.<br>
<br>
To make the global registry easier, we can just use a per-service prefix,<br>
and then keep the error catalogue in the service code repo, pulling them<br>
into some sort of release periodically<br>
<br>
<br>
<br>
[Rockyg]  In discussions at the summit about assigning error codes, we<br>
determined it would be pretty straightforward to build a tool that could be<br>
called when a new code was needed and it would both assign an unused code<br>
and insert the error summary for the code in the DB it would keep to ensure<br>
uniqueness.  If you didn’t provide a summary, it wouldn’t spit out an error<br>
code;-)  Simple little tool that could be in oslo, or some cross-project<br>
code location.<br>
</blockquote>
<br>
Apropos of logging, has <a href="https://tools.ietf.org/html/rfc5424" target="_blank">https://tools.ietf.org/html/<u></u>rfc5424</a> been<br>
considered? Combined with <a href="https://tools.ietf.org/html/rfc5426" target="_blank">https://tools.ietf.org/html/<u></u>rfc5426</a> we'd<br>
have a standards based (and thus already supported by logging and<br>
analysis tools) framework. aka, we seem to be on the verge of<br>
inventing a thing thats already been invented.<br>
</blockquote>
<br>
In what way are either of the above RFCs guidance to our conversation about how to properly codify error codes in our HTTP APIs?<br>
<br>
Best,<br>
-jay<br>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div>