Open Stack

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.mitchell at rackspace.com>
Rackspace