On 06/04/2012 09:55 AM, Jay Pipes wrote:
On 05/30/2012 09:28 PM, Adam Young wrote:
The recent discussion about node.js made me rethink the state of
Websocket support for Apache and Openstack. A quick recap:
1) neither mod_wsgi nor mod_proxy support Web sockets.
2) There is a Websocket Module for Apache, but using it requires an
additional apache module.
3) There is websocket support in Eventlet.
4) The argument for node.js is the same for Eventlet: rapid dispatch to
support a large number of connections
5) noVNC currently uses websockify, and uses a simplistic web server to
proxy over VNC traffic.
The more I think about it, the more I think that the simplest, and most
correct path forward is to use the websocket Apache module, and to write
an additional module that will hook it up to Eventlet. Eventlet can
listen on a local Port (127.0.0.1 only) and Apache will map that to a
suburl. I'll code name it mod_websocket_proxy for now.
<snip>
Adam, other than the NoVNC piece in Nova and the Horizon project in
general, where do you see the need for Websockets in OpenStack? I
could easily be mistaken (happens a lot!), but I see Websockets as a
great tool for client-side and UI interaction, and not so much useful
in the eventlet servers that we use for so many OpenStack services
(nova-api, swift-proxy, glance-api, glance-registry, keystone-api,
etc). Could you elaborate how you see Websockets (and your proposed
mod_websocket_proxy) being useful to OpenStack services outside of
horizon and noVNC?
Jay,
This is predominantly for Horizon. For other communication, I think AMQP
suffices, but we might want to revisit that assumption in the future.
I think that demand for Websockets is what is driving the push toward
Node.js. It is a natural complement to an event driven webserver.
While I think the quetion of noVNC itself justifies investigating
Websocket approaches, I can see the need for Websocket style development
where:
1. We need to traverse firewalls
2. We need the application to predominantly post data to the browser
Thus far we would otherwise choose AMQP for notifications, but it
doesn't seem to be the right solution for these cases. So, what are
these cases?
Log streaming seems to be the first case: a long running task generating
a lot of events, and a user wants to track what is happening as quickly
as they occur. This covers a lot of use cases.
Thanks!
-jay
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
