lp:~frankban/charms/precise/juju-gui/guiserver-ws-chrome

Branch merges

Propose for merging

No branches dependent on this one.

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

charmers: Pending requested 2013-08-29

Diff: 95 lines (+29/-5)

5 files modified

HACKING.md (+5/-4)
Makefile (+5/-0)
revision (+1/-1)
server/guiserver/handlers.py (+12/-0)
server/guiserver/tests/test_handlers.py (+6/-0)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

99. By Francesco Banconi on 2013-08-29

Changes as per review.

98. By Francesco Banconi on 2013-08-29

Merged old branch.

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

94. By Francesco Banconi on 2013-08-21

GUI server: base deployer helpers.

This branch includes some helper functions
and objects that are required to implement
the Deployer and DeployMiddleware classes.

To avoid this branch to include too many
changes, the base classes above will be
implemented in a separate branch.

Tests: `make unittest` from the branch root.

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

93. By Francesco Banconi on 2013-08-20

Bundle deployment views.

This branch includes the implementation of the
bundle views. Their goal is to handle the bundle
deployment request/response process.

Views interact with the Deployer instance
(not yet implemented) in order to schedule,
run and observe bundle deployments.

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

92. By Francesco Banconi on 2013-08-20

GUI server: deployer blocking functions.

This branch includes the functions and objects
required to interact with the juju-deployer library.
These functions are synchronous/blocking, they are
stored in the blocking module (inside the bundles
package) and they will be executed in a separate
process or thread.

Also implemented an InfoHandler that will be useful
when integrating the GUI server with the charm.

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

R=
CC=
https://codereview.appspot.com/13106043

91. By Francesco Banconi on 2013-08-19

Asynchronous watcher for bundle deployments.

This is the first of several branches implementing
the bundle deployments support in the GUI server.

This branch includes an AsyncWatcher implementation:
it will be used to observe the progress of bundle
deployments.

To give you a wider overview of what will be added,
I created the bundle module and added a comprehensive
documentation of the pieces that will be used to
implement the functionality, and a description of the
request/response process.

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

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

90. By Curtis Hovey on 2013-08-14

Add support for nagios-external-master subordinate charm.