Open Stack

On Fri, Jan 30, 2015 at 3:08 PM, Everett Toews <everett.toews at rackspace.com>
wrote:

> I like the idea of the log error codes being aligned with the API errors
> codes but I have some thoughts/concerns.
>
>  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.
>

Agreed that this is not necessary, but it is not objectionable if that
simplifies coding the server side.


> 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.
>

++


> Error Catalog Number: If there could be alignment around this, that would
> be great.
>

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.

dt

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150130/4d84b737/attachment-0001.html>