Open Stack

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