Support for realtime communication

Registered by Gabriel Hurley

Horizon is quickly outgrowing the capabilities that can be satisfied by simple JavaScript polling techniques. The next level of improvement would be to move to real-time communication with the backend via a tool like

The details of such an implementation may materially increase the complexity of deploying the dashboard, so we'll have to weigh the benefits of various solutions and see what makes the most sense, and if graceful fallbacks can be put into place for those who do not wish to deploy a full real-time system.

Blueprint information

Gabriel Hurley
Gabriel Hurley
Tomas Sedovic
Series goal:
Beta Available
Milestone target:
Started by
Gabriel Hurley
Completed by
David Lyle

Related branches



[gabrielhurley] Latest notes from the Havana summit:

The tl;dr is to move forward with a implementation and try a POC python-based websocket backend, possibly such as + gunicorn.


One potential setup would be to leverage node.js and as a side-by-side server handling solely real-time communications while Django does the heavy-lifting. Django and node.js could then communicate via a standard message queue, allowing Django to push updates as it executes code while handles the updates to the client. This would add complexity to the setup/deployment (including an additional port) but compared to other first-glance solutions is one of the lighter-weight, simpler options.

[devcamcar] Requiring another port is not a blocker conceptually, though others have flagged this as a potential security issue. Queue based communications are an eventuality for front end systems as they grow more complex. One thing to consider here is that there are a large number of choices for RPC mechanisms that are exposed within Nova already. This code is not (yet) common. It would be tricky if we only supported one RPC mechanism (such as Rabbit). Due to issues with most systems (qpid, rabbit, etc) all targeting different versions of the pre-1.0 AMQP specification, you end up having to write a driver to support each of them. It's a pain. Something to think about...

[gabriel] It would be lovely if the existing RPC code was part of "common" so that all the projects could mutually benefit from work done there and perhaps even eventually talk to the front-end's queue directly to cut out another layer of indirection in providing real-time updates to the end-user. Otherwise yes, targeting different queue backends would be somewhat of a pain. Interestingly, here's a blog post on exactly the type of deployment setup I proposed up above:

[gabriel] Additionally, for people interested in the difficulties involved in websockets in Python, here's some homework:

  * http://<email address hidden>/2010-04/msg00163.html

The "tl;dr" version? Websockets (and pretty much any form of modern real-time communication) *is* possible with Python, but is so far afield from standard deployment techniques that I see very little value in choosing to go that route and fight for "Python purism" rather than embrace a new, well-understood technology (JavaScript) that's already part of our developers' lexicon. Ironically, in James Burkhart's blog post (linked above) he makes the case in favor of Javascript as a know language by saying:

"No new languages- We didn't want to have to do any significant development with any language our developers were not already familiar with. This basically limited us to Python and Javascript. "

There are clearly issues around distro support for node.js and opening ports, but these are details to be supported in optional support mechanisms, cross-project collaboration, etc.

Gerrit topic:,topic:bp/realtime-communication,n,z

Addressed by:
    Add openstack-common

Addressed by:
    Add SockJS dependency

Addressed by:
    Proof of concept for push-based communication

Addressed by:
    Add SockJS dependency

Addressed by:
    Proof of concept for push-based communication

[2013-08-13 | Gabriel] I'm still strongly committed to making this happen, but I'd rather make a big push to land this in I1 instead of adding it late in H3. Don't get discouraged, we're totally gonna bring this full circle and get it in!

[2014-01-12 david-lyle] Moving to i-3.

Addressed by:
    Proof of concept for push-based communication


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.