openstack team mailing list archive

[Gabriel Hurley <Gabriel.Hurley@xxxxxxxxxx>]

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.

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