lp:~frankban/charms/precise/juju-gui/improve-error-handling

Branch merges

Propose for merging

No branches dependent on this one.

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

charmers: Pending requested 2013-11-07

Diff: 137 lines (+43/-5)

6 files modified

hooks/utils.py (+3/-0)
revision (+1/-1)
server/guiserver/handlers.py (+4/-2)
server/guiserver/tests/bundles/test_base.py (+30/-0)
server/guiserver/tests/test_handlers.py (+3/-0)
tests/requirements.pip (+2/-2)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

125. By Francesco Banconi on 2013-11-07

Lint.

124. By Francesco Banconi on 2013-11-07

Fix the InfoHandler headers.

123. By Francesco Banconi on 2013-11-07

Checkpoint.

122. By Francesco Banconi on 2013-11-07

Bumped revision up.

121. By Francesco Banconi on 2013-11-07

Fix deployer integration.

Fix the deployer error when the bundle includes
services with constraints.

Updated the deployer dependency. The new tarball
is generated from lp:~frankban/juju-deployer/guienv-fixes
I will take care of proposing that branch later, however,
the diff can be found here:
http://pastebin.ubuntu.com/6376113/

This branch includes the work Benji did for fixing
this issue.

TODO: but these are not release blockers IMHO:
- improve the way we handle the set up of
  testing/production environments (as Rick suggested);
- improve the GUI server bundle validation, e.g. disallow
  the deployment of local charms, or better check that the
  YAML structure is what we expect;
- investigate and fix the bundle deployment error handling:
  why errors in the deployer process are not propagated?
  Why concurrent.futures explodes with an error while trying
  to set up the exception to be propagated in the Future?
  This is important because right now an error in the
  deployer is not notified, so the deployment is forever
  considered in progress and all the other deployments
  will be just queued... Actually this is "almost" a release
  blocker.

Tests: make unittest

QA:
I used this bundle: http://pastebin.ubuntu.com/6376098/
to live test the branch.
Bootstrap a juju environment, run `make deploy` and then
switch the gui source to lp:juju-gui.
When everything is ready, try to deploy a bundle
which includes num_units != 1, customized config and
constraints. Check the bundle is deployed correctly
and the resulting services have the defined
number of units, options and constraints.
Now try to deploy a bundle with invalid constraints: right
after the drag and drop, the GUI should notify an
invalid constraints error.

R=rharding, benji
CC=
https://codereview.appspot.com/22810043

120. By Madison Scott-Clary on 2013-10-18

Merged back in with new charm release

119. By Madison Scott-Clary on 2013-10-17

Updated to the newest juju-gui release

118. By Francesco Banconi on 2013-10-17

Fix string encoding problem in guiserver.

The Juju API connection was dropped as
result of an error while logging responses
containing non-ascii characters.

R=gary.poster
CC=
https://codereview.appspot.com/14772044

117. By Gary Poster on 2013-10-14

Add support for xz compression

An xz tarball reduces the size of the gui code by 30 to 40 percent. These changes let the charm use xz tarballs. A very simple change to the gui makefile will follow.

To qa, apply this diff to the gui trunk:

=== modified file 'Makefile'
--- Makefile 2013-10-12 01:30:26 +0000
+++ Makefile 2013-10-14 13:43:10 +0000
@@ -95,7 +95,7 @@
 LAUNCHPAD_API_ROOT=staging
 endif
 RELEASE_NAME=juju-gui-$(RELEASE_VERSION)
-RELEASE_FILE=releases/$(RELEASE_NAME).tgz
+RELEASE_FILE=releases/$(RELEASE_NAME).xz
 RELEASE_SIGNATURE=releases/$(RELEASE_NAME).asc
 NPM_CACHE_VERSION=$(BZR_REVNO)
 NPM_CACHE_FILE=$(CURDIR)/releases/npm-cache-$(NPM_CACHE_VERSION).tgz

Then run ``BRANCH_IS_GOOD=1 make distfile``. Copy over the new release to the charm's releases directory. If you compare the two file sizes in the charm's releases directory, the difference should be dramatic.

$ ls -l
-rw-r--r-- 1 gary gary 5076088 Oct 14 09:44 juju-gui-0.10.1+build.1133.xz
-rw-r--r-- 1 gary gary 44840221 Oct 12 20:15 juju-gui-0.10.1.tgz

You can remove the tgz, and then run juju bootstrap and make deploy in the charm root directory. Once it is deployed, you should be able to log in and see the gui as usual, and you should be able to verify the fact that you are using your custom release if you go to /juju-ui/version.js, where you will see something like "var jujuGuiVersionInfo=['unreleased', '1133'];".

Thank you!

R=bac
CC=
https://codereview.appspot.com/14425057

116. By Francesco Banconi on 2013-10-09

Merged charmers trunk.