On Fri, 2015-01-30 at 21:08 +0000, Everett Toews wrote: > 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.
Do they? We boot a server and interact with Cinder and Neutron, right? What if the nova API is simply forwarding an error that originally came from Cinder? > 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. While I agree with you from a security standpoint, this is probably coming in due to a desire to namespace the errors. Ideally, we'd have a set of common error codes to cover conditions that the API user could rectify ("You picked a nic type we don't support" or something like that), but I fear there may always be errors that are things the API user could rectify but which don't fit into any of those buckets… > Error Catalog Number: If there could be alignment around this, that > would be great. [snip] > Criticality: This might be useful to clients? I don’t know. I don’t > feel too strongly about it. I feel this part of the code needs more thought to properly round out. Is it intended to convey information similar to the distinction between 4xx and 5xx errors in HTTP? ("You made an error" vs. "The server messed up".) Is it intended to convey a retryable condition? ("If you retry this, it may succeed.") If it's intended to convey that the server messed up spectacularly and that everything's broken now, well… :) -- Kevin L. Mitchell <kevin.mitch...@rackspace.com> Rackspace __________________________________________________________________________ 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