lp:~makyo/charms/precise/juju-gui/docs-source

Branch merges

Propose for merging

No branches dependent on this one.

Merged into lp:~juju-gui/charms/precise/juju-gui/trunk at revision 83

charmers: Pending requested 2013-07-30

Diff: 76 lines (+50/-4)

2 files modified

README.md (+49/-3)
revision (+1/-1)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

86. By Madison Scott-Clary on 2013-07-31

Making linter happy.

85. By Madison Scott-Clary on 2013-07-30

Merge with juju-gui-charmers

84. By Madison Scott-Clary on 2013-07-30

Responding to reviews

83. By Madison Scott-Clary on 2013-07-30

Upping revision

82. By Madison Scott-Clary on 2013-07-30

Updated docs, added firewall section.

81. By Nicola Larosa on 2013-07-30

Refactor for easier builtin server integration.

Refactor the charm code to ease integration of the builtin server.
Detail of the changes, per file:

hooks/backend.py:

- order the mixins code as they are called, to ease readability;
- merge InstallMixin into GuiMixin;
- rename UpstartMixin to HaproxyApacheMixin;
- reimplement GuiMixin.install using the new functions from the split of
  hooks/utils.py#fetch_gui (see below);
- reimplement GuiMixin.start using the new functions from the split of
  hooks/utils.py#start_gui (see below);
- move here the chain and merge functions from hooks/utils.py, renaming
  them to be less generic;
- further simplify the backend constructor code.

hooks/utils.py:

- rename JUJU_GUI_SITE and JUJU_GUI_PORTS to APACHE_SITE and
  APACHE_PORTS respectively;
- split the start_gui function into compute_build_dir, write_gui_config
  and write_haproxy_config;
- split the fetch_gui function into fetch_gui_from_branch and
  fetch_gui_release;
- move the chain and merge functions to hooks/backend.py.

tests/test_backends.py:

- rename, add mocks and reorder to make tests pass again.

tests/test_utils.py:

- rename TestStartStop to TestStartImprovAgentGui;
- split the start_gui function tests in TestStartImprovAgentGui into
  tests for compute_build_dir, write_gui_config, write_haproxy_config
  and write_apache_config;

Sorry for the big diff. It was even bigger, but I moved some of the
changes to a future branch.

R=bac, gary.poster
CC=
https://codereview.appspot.com/12022044

80. By Francesco Banconi on 2013-07-26

GUI server supports serving GUI tests.

Added support for serving GUI unit tests
from the Tornado server if the --servetest
parameter is passed.

Also added support for the "ssl-cert-path"
option: the path where the SSL key and cert
files are stored.

Tests:
Run `make unittest` from the branch root.

R=teknico, gary.poster
CC=
https://codereview.appspot.com/11841043

79. By Francesco Banconi on 2013-07-25

GUI server authentication.

Added authentication management to the Tornado server.
The WebSocket handler includes a way to know if the
connected client is logged in to the API server.
Both Go and Python API implementations are supported.

Also implemented WebSocket messages validation.

I am sorry: this diff is quite long.
In my defence, the code is full of tests and
documentation... Well, sorry again.

Tests: `make unittest`

R=benjamin.saller, benji, teknico
CC=
https://codereview.appspot.com/11725044

78. By Francesco Banconi on 2013-07-23

New 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!

R=teknico, gary.poster
CC=
https://codereview.appspot.com/11675043

77. By Brad Crittenden on 2013-07-22

Update charm_store_url to point to new location.

R=rharding
CC=
https://codereview.appspot.com/11525046