GUI server: logging option and sandbox mode.

GUI server: logging option and sandbox mode.

This branch includes three changes:
- the GUI server logging level can now be
  set using a charm option;
- added support for sandbox mode: when the GUI
  is run in sandbox mode, the GUI server avoids
  listening for WebSocket connections;
- fixed a bug preventing the builtin server to work
  when the secure charm option was set to false.

Tests: `make unittest` from the branch root.

QA:

In the steps below I assume your default juju is
juju-core and your juju-core env is named "go".

- Bootstrap a juju-core environment:

  juju bootstrap -e go --upload-tools

- From the root of this branch, deploy and expose
  the GUI running the following:

  make deploy JUJU_ENV=go

  The command above will exit when the GUI is ready.

- Switch to the GUI server, then wait a minute for the
  server to be ready:

  juju set -e go juju-gui builtin-server=true

- In a separate terminal tab, start watching the GUI server log
  (the first line should be "starting Juju GUI server v0.1.0"):

  juju ssh -e go 1 sudo tailf /var/log/upstart/guiserver.log

- Use the browser to navigate the GUI, log in and check
  everything works fine.

- Set the logging level to debug, then wait a minute for the
  cahnge to be applied:

  juju set -e go juju-gui builtin-server-logging=debug

- Now the contents of the WebSocket messages should be
  included in the GUI server logs.

- Switch to HTTP mode, then wait a minute for the
  cahnge to be applied:

  juju set -e go juju-gui secure=false

- Visit the GUI using http:// and check everything
  works fine.

  Note that at this time it is impossible to QA sandbox
  mode in a juju-core env. This will be fixed in a future
  branch.

https://code.launchpad.net/~frankban/charms/precise/juju-gui/guiserver-logging-sandbox/+merge/182601

(do not edit description out of merge proposal)

[frankban, 2013-08-28 11:13:34]

Please take a look.

[rharding, 2013-08-28 12:20:53]

code looks good, qa'ing

[rharding, 2013-08-28 13:40:09]

LGTM QAs ok using local lxc. Thanks for the nice walk through.

When testing in chrome dev channel (v31) using the tornado server would result
in the same websocket errors that came up in rapi. 

 Error during WebSocket handshake: Sec-WebSocket-Protocol mismatch

Per hazmat, " chrome was setting the value to undefined, i just had it return
it"

[gary.poster, 2013-08-28 15:47:35]

LGTM with super trivial typo fix.  Thank you!

Gary

https://codereview.appspot.com/13340043/diff/1/hooks/utils.py
File hooks/utils.py (right):

https://codereview.appspot.com/13340043/diff/1/hooks/utils.py#newcode557
hooks/utils.py:557: 'serve_tests': serve_tests,
Small thing, but I like how this addition made the config template easier to
read.

https://codereview.appspot.com/13340043/diff/1/server/guiserver/apps.py
File server/guiserver/apps.py (right):

https://codereview.appspot.com/13340043/diff/1/server/guiserver/apps.py#newco...
server/guiserver/apps.py:54: server_handlers.append(
This is so nice, to be able to just drop the component in when we want it!

https://codereview.appspot.com/13340043/diff/1/server/guiserver/tests/test_ap...
File server/guiserver/tests/test_apps.py (right):

https://codereview.appspot.com/13340043/diff/1/server/guiserver/tests/test_ap...
server/guiserver/tests/test_apps.py:106: # The WebScoket handler is excluded if
sandbox mode is enabled.
typo, WebSocket

[frankban, 2013-08-28 17:11:36]

*** Submitted:

GUI server: logging option and sandbox mode.

This branch includes three changes:
- the GUI server logging level can now be
  set using a charm option;
- added support for sandbox mode: when the GUI
  is run in sandbox mode, the GUI server avoids
  listening for WebSocket connections;
- fixed a bug preventing the builtin server to work
  when the secure charm option was set to false.

Tests: `make unittest` from the branch root.

QA:

In the steps below I assume your default juju is
juju-core and your juju-core env is named "go".

- Bootstrap a juju-core environment:

  juju bootstrap -e go --upload-tools

- From the root of this branch, deploy and expose
  the GUI running the following:

  make deploy JUJU_ENV=go

  The command above will exit when the GUI is ready.

- Switch to the GUI server, then wait a minute for the
  server to be ready:

  juju set -e go juju-gui builtin-server=true

- In a separate terminal tab, start watching the GUI server log
  (the first line should be "starting Juju GUI server v0.1.0"):

  juju ssh -e go 1 sudo tailf /var/log/upstart/guiserver.log

- Use the browser to navigate the GUI, log in and check
  everything works fine.

- Set the logging level to debug, then wait a minute for the
  cahnge to be applied:

  juju set -e go juju-gui builtin-server-logging=debug

- Now the contents of the WebSocket messages should be
  included in the GUI server logs.

- Switch to HTTP mode, then wait a minute for the
  cahnge to be applied:

  juju set -e go juju-gui secure=false

- Visit the GUI using http:// and check everything
  works fine.

  Note that at this time it is impossible to QA sandbox
  mode in a juju-core env. This will be fixed in a future
  branch.

R=rharding, gary.poster
CC=
https://codereview.appspot.com/13340043

[frankban, 2013-08-28 17:15:32]

Thank you both for the reviews!