OpenStack Dashboard (Horizon)

Improve user feedback and error handling

Registered by Matthias Runge

Currently, when an underlying error occurs, dashboard just returns 500 server error. The original error is well hidden from the user.
For new persons, and especially for people setting up OpenStack in their own environment this will become frustrating. Supporting is just impossible, because people just could report that server error. Looking for the root of that error can be painful and tedious.

Also, when e.g. nova-api service doesn't answer for some reason, horizon fails badly.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Gabriel Hurley

Related branches

Sprints

Whiteboard

[gabriel] The horizon.exeptions.handle and horizon.exceptions.check_message methods both exist to deal with these problems in exactly the standardized, centralized ways you describe. 500 error pages are only served when there's an uncaught exception, which can be safely called a programming error. As for the problems with unresponsive services, I'm open to suggestions on how to improve the clients' socket timeout handling, but that's a fundamental flaw that extends well beyond Horizon. Having a functional Stack behind the dashboard is required for it's proper operation, and the required services are well-documented. For now I'm marking this as "obsolete" (since there's no way to simply close a blueprint). If there are specific suggestions for improvements you can either add them to the whiteboard here, or open them as new bugs/blueprints. Lastly, in the future please give blueprints a descriptive name, not your username.

[mrunge]
Agreed, having not a descriptive name should absolutely be avoided.

Last week I was debugging an OpenStack installation, which just returned 500 server error. Checking the services themself, returned no error. It turned out, not all necessary services were configured. In that case, I think volumes were disabled at that point. As a new user, you don't have a chance to find that. Sadly, that's not the only situation, where this 500 error is returned. Just look to the openstack list. Nearly every message belonging to the Dashboard has a stack trace with that 500 error, changing some configuration fixes it, without a line of code touched.

Maybe we could improve the situation by also providing a more descriptive status page:
service ... on host ... is up and running
service ... on host ... is ....

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.
Edit subscription

Subscribers

No subscribers.