*** Submitted:

GUI server: cancel deployment feature.

Added an API call for cancelling a pending
deployment.

Also updated the bundles module documentation.

For this first implementation, I discussed
with Gary a workaround to avoid scheduled
deployments to be included in the ProcessPool
executor's call queue: a time.sleep call is
added to the queue right after a new deployment.
This way, as described in the code, it is still
possible to cancel a scheduled deployment job
even if it is the first in the queue.

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

QA:
- bootstrap a juju-core environment;
- deploy the GUI from this branch (`make deploy`);
- switch to the builtin server:
   `juju set juju-gui builtin-server=true`;
- ensure the GUI is working well by visiting
   https://GUI-ADDRESS .

To test the deployer support and the
"cancel deployment" feature, use the script in
http://pastebin.ubuntu.com/6100815/ e.g.:

- download and save the Python script;
- run it passing the GUI node address as first argument:
   `python start-deployer-cancel.py GUI-ADDRESS`.

The script does the following:
1) it logs in to the juju-core API server;
2) it starts/schedules three deployments;
3) it send two invalid Cancel requests;
4) it cancels the second deployment;
5) it shows the deployments status before and
    after the deployment deletion.

- if everything is ok, you should see an output like
this: http://pastebin.ubuntu.com/6100861/ ;
- you should also be able to check the deployment
   progress from the GUI;
- when the two deployments are completed (it may take
   some minutes) you should see wordpress, mysql and
   mediawiki correctly deployed and displayed in the
   topology view;
- visiting https://GUI-ADDRESS/gui-server-info you
   should see something like this:
   {
     "uptime": 970,
     "deployer": [
       {"Status": "completed", "DeploymentId": 0, "Time": 1379062144},
       {"Status": "cancelled", "DeploymentId": 1, "Time": 1379061766},
       {"Status": "completed", "DeploymentId": 2, "Time": 1379062156}
     ],
     "apiversion": "go",
     "sandbox": false,
     "version": "0.2.0",
     "debug": false,
     "apiurl": "wss://ec2-50-17-116-51.compute-1.amazonaws.com:17070"
   }

That's all, thanks a lot for QAing this branch!

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



https://codereview.appspot.com/13549046/diff/1/server/guiserver/bundles/base.py
File server/guiserver/bundles/base.py (right):

https://codereview.appspot.com/13549046/diff/1/server/guiserver/bundles/base.py#newcode152
server/guiserver/bundles/base.py:152: # cancelling scheduled jobs, even
if the job is the next to be started.
On 2013/09/13 14:33:19, bac wrote:
> It's not clear to my why you want to be able to cancel this first job.
  Only
> giving a window of 1 second seems arbitrary.  Perhaps the use case
will become
> clearer as I read more code.

It is arbitrary indeed. This is just a way to fill the call queue so
that, when a job starts (and it is removed from the queue) he sleep is
put in the queue and the next deployment can still be cancelled. This is
just a workaround, and will be changed in the future, likely
implementing our own async queue.

https://codereview.appspot.com/13549046/