Fix "Include error message in instance faults" to resolve more messages
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Undecided
|
Ben Nemec |
Bug Description
The previous bug and fix for "Include error message in instance faults" (https:/
We should be using unicode(exception) for the error message, as that is the recommended way of getting an error message from an exception (see http://
Example where resolving a message fails:
In the first example, IOError has no .kwargs or .message attributes, but unicode(exception) yields the message that is the first line in the 'details' item.
| fault | {u'message': u'IOError', u'code': 500, u'details': u'[Errno 28] No space left on device |
| | File "/opt/stack/
| | return function(self, context, *args, **kwargs) |
| | File "/opt/stack/
| | block_device_
| | File "/opt/stack/
| | admin_pass=
| | File "/opt/stack/
| | project_
| | File "/opt/stack/
| | *args, **kwargs) |
| | File "/opt/stack/
| | prepare_
| | File "/opt/stack/
| | retval = f(*args, **kwargs) |
| | File "/opt/stack/
| | fetch_func(
| | File "/opt/stack/
| | images.
| | File "/opt/stack/
| | fetch(context, image_href, path_tmp, user_id, project_id) |
| | File "/opt/stack/
| | image_service.
| | File "/opt/stack/
| | data.write(chunk)
Changed in nova: | |
status: | New → Confirmed |
Changed in nova: | |
milestone: | none → havana-3 |
status: | Fix Committed → Fix Released |
Changed in nova: | |
milestone: | havana-3 → 2013.2 |
Relevant to this topic are the comments on https:/ /review. openstack. org/#/c/ 28391/
Basically, the error information is available in the details field, but that's not supposed to be visible to end users. So if this error were to happen in a production environment, the user would see "500: IOError" and have no idea whether the problem is on their end or the provider's. That's rather unfriendly behavior IMHO, and it can be fixed as Matt suggests in the bug description above.
I had also suggested maybe we take the message out of the details field and only put the stack trace there to avoid duplication. That's probably a topic for when a fix gets proposed.