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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to