lp://staging/~bac/charms/precise/juju-gui/trunk
- Get this branch:
- bzr branch lp://staging/~bac/charms/precise/juju-gui/trunk
Branch merges
- charmers: Pending requested
-
Diff: 35 lines (+10/-5)2 files modifiedMakefile (+9/-4)
revision (+1/-1)
Branch information
- Owner:
- Brad Crittenden
- Status:
- Development
Recent revisions
- 122. By Francesco Banconi
-
Improve bundle deployment error handling.
Workaround for http://
bugs.python. org/issue169233 5. 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
-
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 - 118. By Francesco Banconi
-
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
-
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.tgzYou 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 jujuGuiVersionI nfo=['unrelease d', '1133'];". Thank you!
R=bac
CC=
https://codereview. appspot. com/14425057
Branch metadata
- Branch format:
- Branch format 7
- Repository format:
- Bazaar repository format 2a (needs bzr 1.16 or later)
- Stacked on:
- lp://staging/charms/juju-gui