Hi all, The first draft of the spec for Log Message Error Codes (from the Log Working Group) is out for review:
https://review.openstack.org/#/c/172552/ Please comment, and please look for the way forward so that the different places, ways and reasons errors get reported provide consistency across the projects the make up the Openstack ecosystem. Consistency across uses will speed problem solving and will provide a common language across the diversity of users of the OpenStack code and environments. This cross project spec is focused on just a part of the Log Message "header", but it is the start of where log messages need to go. It dovetails in with developer focused API errors, but is aimed at the log files the operators rely on to keep their clouds running. Over the next couple of days, I will also specifically add reviewers to the list if you haven't already commented on the spec;-). Thanks for your patience waiting for this. It *is* a work in progress, but I think the meat is there for discussion. Also, please look at and comment on: Return Request ID to caller https://review.openstack.org/#/c/156508/ as this is also critical to get right for logging and developer efforts. --Rocky -----Original Message----- From: Everett Toews [mailto:everett.to...@rackspace.com] Sent: Tuesday, March 31, 2015 14:36 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [all] [api] Erring is Caring Hi All, An API Working Group Guideline for Errors https://review.openstack.org/#/c/167793/ Errors are a crucial part of the developer experience when using an API. As developers learn the API they inevitably run into errors. The quality and consistency of the error messages returned to them will play a large part in how quickly they can learn the API, how they can be more effective with the API, and how much they enjoy using the API. We need consistency across all services for the error format returned in the response body. The Way Forward I did a bit of research into the current state of consistency in errors across OpenStack services [1]. Since no services seem to respond with a top-level "errors" key, it's possible that they could just include this key in the response body along with their usual response and the 2 can live side-by-side for some deprecation period. Hopefully those services with unstructured errors should okay with adding some structure. That said, the current error formats aren't documented anywhere that I've seen so this all feels fair game anyway. How this would get implemented in code is up to you. It could eventually be implemented in all projects individually or perhaps a Oslo utility is called for. However, this discussion is not about the implementation. This discussion is about the error format. The Review I've explicitly added all of the API WG and Logging WG CPLs as reviewers to that patch but feedback from all is welcome. You can find a more readable version of patch set 4 at [2]. I see the "id" and "code" fields as the connection point to what the logging working group is doing. Thanks, Everett [1] https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Errors [2] http://docs-draft.openstack.org/93/167793/4/check/gate-api-wg-docs/e2f5b6e//doc/build/html/guidelines/errors.html __________________________________________________________________________ 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 __________________________________________________________________________ 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
