On Jan 29, 2015, at 8: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? This also allows for a unique message to be associated with the error code that is more descriptive and that can be pre translated. Again, for logging purposes, the error code would not be part of the message payload, but part of the headers. Referrer IDs and other info would still be expected in the payload of the message and could include instance ids/names, NICs or VIFs, etc. The message headers is code in Oslo.log and when using the Oslo.log library, will be easy to use. Since this discussion came up, I thought I needed to get this info out to folks and advertise that anyone will be able to comment on the spec to drive it to agreement. I will be advertising it here and on Ops and Product-WG mailing lists. I’d also like to invite anyone who want to participate in discussions to join them. We’ll be starting a bi-weekly or weekly IRC meeting (also announced in the stated MLs) in February. And please realize that other than Oslo.log, the changes to make the errors more useable will be almost entirely community created standards with community created tools to help enforce them. None of which exist yet, FYI. Hi Rocky, The API WG is trying to come up with a guideline for an error format for the HTTP APIs [1]. In that error format is a code field that I was hoping could match the code in the logs you mention above. I noticed in the Logging WG meetings [2] that you mention an "Error Code Spec”. I’d like to be able to use info from that spec in the example [2] of the error format. Has there been any progress on that spec? Can you link me to it? Also, if you have time for a review of the error format, I’d like to hear your thoughts. Thanks, Everett [1] https://review.openstack.org/#/c/167793/ [2] https://wiki.openstack.org/wiki/Meetings/log-wg [3] https://review.openstack.org/#/c/167793/4/guidelines/errors-example.json,unified
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
