OpenStack Dashboard (Horizon)

Horizon doesn't timeout promptly when services can't be reached

Bug #1415925 reported by Doug Fish
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Confirmed
Low
Unassigned

Bug Description

If network connectivity is lost between Horizon and the other services it can take quite a while (between 1 minute and "forever") before Horizon returns with any timeout message. Each of the multiple API calls it takes to render a page has to timeout serially before the page is returned.

I think the fix should involve passing a timeout value to the python clients. I've surveyed a few and they support it (I assume they all do). In an environment where this may be a problem a service_timeout value can be configured and passed in to the client.

Nikunj Aggarwal (nikunj2512)
Changed in horizon:
assignee: nobody → Nikunj Aggarwal (nikunj2512)
Revision history for this message
Doug Fish (drfish) wrote :

I was just encountering another version of this problem: some regions have become inaccessible for a longer period of time.

I wonder if we could share this kind of information between users. So that we somehow recognize, for example, RegionOne is not available and we just checked it 5 seconds ago - let's not attempt to reach it again for a minute or 2 for any user. Maybe some keep some kind of global state/health of a region.

Revision history for this message
Matthias Runge (mrunge) wrote :

It would be great to have proper timeouts for python-*client calls, hopefully with fallbacks.

Currently, horizon relies on stable services below, and it fails quite ugly, if they are not available.

For Dougs idea, we would need to have access to HA layer somewhere, as that data must be available there, too. Somehow that screams for a new service / OpenStack project.

Rob Cresswell (robcresswell-deactivatedaccount)
Changed in horizon:
assignee: Nikunj Aggarwal (nikunj2512) → nobody
Revision history for this message
Matt Borland (palecrow) wrote :

It seems that this requires a blueprint as it's a far-reaching problem. Also, as we shift to an async client-side interface that processes timeouts on its own, this shifts the issue somewhat from the API layer to async behaviors on the client side. I suggest calling this Low for now, and having someone write a blueprint if they think it's important.

Changed in horizon:
status: New → Confirmed
importance: Undecided → Low
Atsuko Ito (yottatsa)
Changed in horizon:
assignee: nobody → Vladimir Eremin (yottatsa)
Revision history for this message
Akihiro Motoki (amotoki) wrote :

Clearing the assignee due to inactivity.

Changed in horizon:
assignee: Vladimir Eremin (yottatsa) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.