Comment 4 for bug 725349

A stack trace is debugging information, pure and simple. Users (e.g., Nova admins) as a rule don't have the tools or knowledge to interpret the stack trace. Now, for most exceptions, obviously, the thing to do is email the stack trace to the developers. However, there are some exceptions which are not errors the developers can do anything about--things like not being able to reach the database server, for instance, which I can't figure out a way to do without violating abstraction boundaries. In those cases, the stack traces are noise for *both* developers *and* users.

The idea here is that, in the normal case where a user has set up Nova, the log files contain only the actual exception information, minus stack traces. That exception information can be useful to the user ("Hmmm, can't reach my database server, I wonder why?"). If they run across an actual Nova bug, on the other hand, they re-start the appropriate Nova service with --verbose, replicate the bug, then attach the stack trace.

This idea/bug, by the way, came out of a conversation vishy and I had regarding stack traces in the case that the AMQP server could not be reached. In that case, it was easy to intercept the exception without violating abstraction boundaries (in fact, the exception was already being caught and the connection was being retried), but it was almost impossible to determine, from the log, what was happening because of the noise from the stack traces. I made the same point to him ("stack traces are for developers!"), and he made a comment to the effect that perhaps we could suppress stack traces unless --verbose was specified. As it turns out, this was the only way I could see to fix a similar noise issue related to the database server being unreachable.