<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 30, 2015 at 3:08 PM, Everett Toews <span dir="ltr"><<a href="mailto:everett.toews@rackspace.com" target="_blank">everett.toews@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word"><div><div>I like the idea of the log error codes being aligned with the API errors codes but I have some thoughts/concerns.</div>
<div><br>
</div>
<div>Project: A client dealing with the API already knows what project (service) they’re dealing with. Including this in an API error message would be redundant. That’s not necessarily so bad and it could actually be convenient for client logging purposes to
 have this there.</div></div></div></blockquote><div><br></div><div>Agreed that this is not necessary, but it is not objectionable if that simplifies coding the server side.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>
<div>Vendor/Component: Including any vendor information at all would be leaking implementation details. This absolutely cannot be exposed in an API error message. Even including the component would be leaking too much.</div></div></div></blockquote><div><br></div><div>++</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>
<div>Error Catalog Number: If there could be alignment around this, that would be great.</div></div></div></blockquote><div><br></div><div>I think the important alignment here is being able to trace a client-side API error back to the service log for further research.  This might not be a high-volume use, but I have to do this all the time for chasing down client-side dev issues.  Its easy in DevStack, but in a deployed cloud of any size not so much.  A timestamp and _anything_ that can map the user-visible error into a log file is all that is really needed.  We often can't even do that today.</div><div><br></div><div>dt</div><div><br></div></div>-- <br><div class="gmail_signature"><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br></div>
</div></div>