Support for realtime communication
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 socket.io.
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
- Status:
- Complete
- Approver:
- Gabriel Hurley
- Priority:
- High
- Drafter:
- Gabriel Hurley
- Direction:
- Approved
- Assignee:
- Tomas Sedovic
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Beta Available
- Milestone target:
- None
- Started by
- Gabriel Hurley
- Completed by
- David Lyle
Related branches
Related bugs
Sprints
Whiteboard
[gabrielhurley] Latest notes from the Havana summit: https:/
The tl;dr is to move forward with a socket.io implementation and try a POC python-based websocket backend, possibly such as https:/
-------
One potential setup would be to leverage node.js and socket.io 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 socket.io 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: http://
[gabriel] Additionally, for people interested in the difficulties involved in websockets in Python, here's some homework:
* http://
* http://<email address hidden>
* http://
* http://
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: https:/
Addressed by: https:/
Add openstack-common
Addressed by: https:/
Add SockJS dependency
Addressed by: https:/
Proof of concept for push-based communication
Addressed by: https:/
Add SockJS dependency
Addressed by: https:/
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: https:/
Proof of concept for push-based communication
Work Items
Dependency tree
* Blueprints in grey have been implemented.
