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

[Doug Fish]

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.

[Doug Fish (drfish)]

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.

[Matthias Runge (mrunge)]

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.

[Matt Borland (palecrow)]

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.

[Akihiro Motoki (amotoki)]

Clearing the assignee due to inactivity.