lp://staging/~frankban/charms/precise/juju-gui/enable-go-sandbox

Branch merges

Propose for merging

No branches dependent on this one.

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

charmers: Pending requested 2013-08-30

Diff: 218 lines (+87/-58)

5 files modified

Makefile (+1/-1)
hooks/backend.py (+9/-14)
revision (+1/-1)
tests/20-functional.test (+9/-0)
tests/test_backends.py (+67/-42)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

104. By Francesco Banconi on 2013-08-30

Checkpoint

103. By Francesco Banconi on 2013-08-30

Add builtin/staging tests.

102. By Francesco Banconi on 2013-08-29

Bumped revision up.

101. By Francesco Banconi on 2013-08-29

Increased timeout.

100. By Francesco Banconi on 2013-08-29

Lint.

99. By Francesco Banconi on 2013-08-29

Checkpoint.

98. By Francesco Banconi on 2013-08-29

Fix Chrome dev WebSocket sub-protocol error.

Also updated the way we suggest to install
system dependencies.

Tests: `make unittest` from the branch root.

QA:

- Install the system dependencies by running the
  following command from the root of this branch:

  make sysdeps

- Bootstrap a juju-core environment:

  juju bootstrap --upload-tools

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

  make deploy

  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 juju-gui builtin-server=true

- With a development version of the Chrome browser
  (>=30), visit the GUI and check everything works well.

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

97. By Francesco Banconi on 2013-08-28

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

96. By Francesco Banconi on 2013-08-27

GUI server: bundles support integration.

This branch enables the GUI server bundles support.
Changed the hooks so that the new GUI server
dependencies are installed.
Also added more info to the info handler.

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.

- Also visit the /gui-server-info URL path: you should see
  something like:
  {
    "uptime": 77,
    "deployer": [],
    "apiversion": "go",
    "version": "0.1.0",
    "debug": false,
    "apiurl": "wss://ec2-54-211-156-178.compute-1.amazonaws.com:17070"
  }

- Let's live test the deployer support: to do that, we will
  use the script in http://pastebin.ubuntu.com/6028073/

- Download the script, edit the PASSWORD value (line 17) and
  execute it passing the Juju GUI node address as first argument, e.g.:

    python start-deployer.py ec2-54-227-188-14.compute-1.amazonaws.com

- The script runs several API calls, simulates errors
  in the API parameters (which should also be notified in the GUI
  server logs), starts two deployments and start watching the
  second one. It takes some minutes to complete. In the meanwhile,
  you should be able to see the relevant changes in the topology view.
  At the end of the process, the GUI should show three started
  services (wordpress and mysql, connected to each other, and
  mediawiki), and the output of the script should be similar to
  this one: http://pastebin.ubuntu.com/6028121/

  Note that I added a card to create a charm functional test that
  automates this live check.

- Switch back to the legacy server (haproxy + apaxche2):

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

- Refresh the browser and check everything is ok.

Done, thank you!

R=bac, rharding
CC=
https://codereview.appspot.com/12741051

95. By Francesco Banconi on 2013-08-26

GUI server: Deployer and DeployMiddleware.

This branch includes the bundles support
base classes. They are already described
in the bundles package docstring.

The diff is a bit long, sorry about that.
Most of the new code are tests.
The next branch will integrate and enable
the bundle support in the GUI server.

Tests: `make unittest` from the branch root.

R=benji, bac
CC=
https://codereview.appspot.com/12802045