On Jan 29, 2015, at 7:34 PM, Rochelle Grober <rochelle.gro...@huawei.com<mailto:rochelle.gro...@huawei.com>> wrote:
Hi folks! Changed the tags a bit because this is a discussion for all projects and dovetails with logging rationalization/standards/ At the Paris summit, we had a number of session on logging that kept circling back to Error Codes. But, these codes would not be http codes, rather, as others have pointed out, codes related to the calling entities and referring entities and the actions that happened or didn’t. Format suggestions were gathered from the Operators and from some senior developers. The Logging Working Group is planning to put forth a spec for discussion on formats and standards before the Ops mid-cycle meetup. Working from a Glance proposal on error codes: https://review.openstack.org/#/c/127482/ and discussions with operators and devs, we have a strawman to propose. We also have a number of requirements from Ops and some Devs. Here is the basic idea: Code for logs would have four segments: Project Vendor/Component Error Catalog number Criticality Def [A-Z] [A-Z] [A-Z] - [{0-9}|{A-Z}][A-Z] - [0000-9999]- [0-9] Ex. CIN- NA- 0001- 2 Cinder NetApp driver error no Criticality Ex. GLA- 0A- 0051 3 Glance Api error no Criticality Three letters for project, Either a two letter vendor code or a number and letter for 0+letter for internal component of project (like API=0A, Controller =0C, etc), four digit error number which could be subsetted for even finer granularity, and a criticality number. This is for logging purposes and tracking down root cause faster for operators, but if an error is generated, why can the same codes be used internally for the code as externally for the logs? 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. 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. Criticality: This might be useful to clients? I don’t know. I don’t feel too strongly about it. Thanks, Everett
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
