Issue 11675043: New WebSocket connection implementation.
DescriptionNew WebSocket connection implementation.
This branch includes a new WebSocket client
implementation purely based on Tornado.
Dropped the ws4py dependency, previously introduced
as a consequence of the built-in client not
being able to connect to juju-core.
Investigation:
I investigated this problem and found that the
WebSocket server implementation in the standard
go.net library (used by juju-core) requires the
"Origin" header to be sent by the client when the
WebSocket handshake is initiated.
See https://code.google.com/p/go/source/browse/websocket/hybi.go?repo=net#514
lines 514-517.
However, if I read the RFC correctly, this is
not entirely the right behavior: see
http://tools.ietf.org/html/rfc6455#page-18 subsection 8:
"The request MUST include a header field with the name |Origin|
[RFC6454] if the request is coming from a browser client. If
the connection is from a non-browser client, the request MAY
include this header field if the semantics of that client match
the use-case described here for browser clients."
This MP description is going to be long anyway, so please
excuse me if I add some background not really related to
the branch. I was curious about why the Python WebSocket
client library that I traditionally used to live test
the juju-core API changes (python-websocket-client) always
work with the juju-core server. The answer ended up being: if no
origin is provided, that library include as "Origin" in
the request headers the address of the WebSocket server itself
(see https://github.com/liris/websocket-client/blob/master/websocket.py#L441
lines 441-444).
I am not sure this make any sense, but I decided to adopt
this solution as fallback for the client in this branch, i.e.:
if the browser request includes the origin header
(it always should), that header is propagated; otherwise
I send the juju-core API server address.
To be clear, the more I think about it, the more I am
convinced that this is NOT a bug in the Tornado client
(which, anyway, allows for adding arbitrary headers almost
easily, as shown in the code).
That's it: I am really interested in your opinion.
Other changes:
Improved logging.
Moved the message queue from the client to the server.
Improved the way disconnections are handled (both browser
and Juju API disconnections).
Improved the way possible API connection problems are handled.
Tests:
Run `make unittest` from the branch root.
QA:
It's not required and, at this time, not easy to set up.
Do it only if you are particularly interested/curious.
Instructions follow.
- Bootstrap juju-core, deploy and expose the juju-gui charm:
juju bootstrap -e go --upload-tools
juju deploy -e go cs:precise/juju-gui
juju expose -e go juju-gui
- Run `juju status -e go` and retrieve the bootstrap
node and the juju-gui addresses. From now on, I will
call the former JUJU-BOOTSTRAP-ADDRESS and the latter
JUJU-GUI-ADDRESS.
- Wait until the juju-gui service is started.
- Get a copy of this branch:
bzr branch lp:~frankban/charms/precise/juju-gui/new-ws-client/
- Copy the gui-server files in the juju-gui node by
running the following command from the branch root:
rsync -av server/ ubuntu@JUJU-GUI-ADDRESS:/home/ubuntu/server
- Ssh into the juju-gui machine:
juju ssh -e go 1
- In the juju-gui node, all the commands must be run as root:
sudo -i
- Stop apache and haproxy:
service apache2 stop
service haproxy stop
- Set up the gui-server dependencies:
apt-get install python-pip
pip install tornado
- Start the gui-server:
cd /home/ubuntu/server/
python runserver.py \
--guiroot="/var/lib/juju/agents/unit-juju-gui-0/charm/juju-gui/build-prod" \
--jujuapi="wss://JUJU-BOOTSTRAP-ADDRESS:17070"
- Navigate to JUJU-GUI-ADDRESS with your browser. You should be
redirected to https://JUJU-GUI-ADDRESS. Accept the untrusted
certificate and start playing with the GUI.
- See the terminal for gui-server access logs. To enable debug
logging, quit the server (CTRL-c) and restart it adding `--logging=debug`
to the list of the options above. At this point the output should
include the contents of the received WebSocket messages.
- Done, thank you!
https://code.launchpad.net/~frankban/charms/precise/juju-gui/new-ws-client/+merge/176218
(do not edit description out of merge proposal)
Patch Set 1 #
Total comments: 19
Patch Set 2 : New WebSocket connection implementation. #
MessagesTotal messages: 5
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
