On Fri, Jan 30, 2015 at 3:08 PM, Everett Toews <[email protected]> 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 [email protected]
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
