← Back to team overview

openstack team mailing list archive

Re: Websocket support long term

 

On 06/04/2012 04:31 PM, Gabriel Hurley wrote:
Log streaming is definitely a good example use case. And as you said, this is mainly relevant to browser-server communications; less so to the backend stack to my knowledge.

In thinking more on the websocket approach that Horizon might take in the future, I have come to this thought:

What websocket backend Horizon talks to should ultimately be a trivially interchangeable component. It's effectively a naïve passthrough. The critical bits are making sure that Horizon's Python codebase sends messages out to an appropriate mechanism (such as one of OpenStack's chosen message queue systems) and that the client-side code has a well-defined mechanism for processing the expected input via a websocket connection if available.

The component that sits between the queue and the websocket should be implemented to do as little work as possible. Thereby I might chose to write a solution in node.js using socket.io, and you might chose to write one in Python using tornado and gevent. There could be options in Ruby or Java or anything else if the community wants to write them. Others might chose not to deploy any realtime option for a minimal deployment scenario.

+1. This pretty much lines up with my views. I don't think we want to expose that much via websockets for the default implementation, but where we do, we need to keep an eye on the performance aspects of it.

I realize this largely doesn't impact your work on the noVNC aspect, but I thought this might be a fresh perspective on the websocket debate.



     - Gabriel


-----Original Message-----
From: openstack-bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-
bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of
Adam Young
Sent: Monday, June 04, 2012 9:17 AM
To: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] Websocket support long term

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


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp



References