lp:~bac/charms/precise/juju-gui/trunk

Branch merges

Propose for merging

No branches dependent on this one.

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

charmers: Pending requested 2013-11-12

Diff: 35 lines (+10/-5)

2 files modified

Makefile (+9/-4)
revision (+1/-1)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

126. By Brad Crittenden on 2013-11-12

Bump rev

125. By Brad Crittenden on 2013-11-12

Add test to Makefile to ensure JUJU_ENV is set when needed.

124. By Richard Harding on 2013-11-07

Merge with charmers-trunk

123. By Richard Harding on 2013-11-07

Updated to juju-gui release 0.12.0

122. By Francesco Banconi on 2013-11-07

Improve bundle deployment error handling.

Workaround for http://bugs.python.org/issue1692335.

Include a customized jujuclient tarball in the
charm, The diff with the original is here:
http://pastebin.ubuntu.com/6377430/

Add a first fix to the testing environment creation
so that the local dependencies are installed
when available.

Also fixed the headers sent by the info handler.

Tests: make unittest

QA:
I used this bundle: http://pastebin.ubuntu.com/6377441/
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 the bundle above:
it will fail because it includes local charms, but the
server will not explode, and it will be possible
to deploy other valid bundles after the first one.
The GUI user does not receive notifications, and that's
normal since deployments are not yet watched by the GUI.
Go to https://[GUI URL]/gui-server-info and you should
find the deployment status to be completed with the
expected error.

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

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