GUI server: cancel deployment feature.

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!

https://code.launchpad.net/~frankban/charms/precise/juju-gui/cancel-deployment/+merge/185448

(do not edit description out of merge proposal)

[frankban, 2013-09-13 09:30:52]

Please take a look.

[frankban, 2013-09-13 09:38:40]

I forgot to mention that you need to change the PASSWORD
at line #17 of the script, setting your own admin secret, 
before running the script itself.

[rharding, 2013-09-13 13:16:21]

code ok, will qa next. Just have the one objection to camel cased http params.

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

https://codereview.appspot.com/13549046/diff/1/server/guiserver/bundles/views...
server/guiserver/bundles/views.py:182: deployment_id =
request.params.get('DeploymentId')
caps in the query string? why not match the var name used deployment_id?

[frankban, 2013-09-13 13:24:32]

On 2013/09/13 13:16:21, rharding wrote:

> server/guiserver/bundles/views.py:182: deployment_id =
> request.params.get('DeploymentId')
> caps in the query string? why not match the var name used deployment_id?

params is not really a querystring, it's the content of the Params field
included in the WebSocket message. Caps are used for consistency with all
the other juju-core API calls.

[rharding, 2013-09-13 13:40:40]

On 2013/09/13 13:24:32, frankban wrote:
> On 2013/09/13 13:16:21, rharding wrote:
> 
> > server/guiserver/bundles/views.py:182: deployment_id =
> > request.params.get('DeploymentId')
> > caps in the query string? why not match the var name used deployment_id?
> 
> params is not really a querystring, it's the content of the Params field
> included in the WebSocket message. Caps are used for consistency with all
> the other juju-core API calls.

Ah, ok. In pyramid/charmworld request.params is a map into request.GET/POST.

[rharding, 2013-09-13 13:45:00]

LGTM

Results of the script, first run:

http://paste.mitechie.com/show/1020/

I did run it a second time and got an error:

http://paste.mitechie.com/show/1021/

I'm not sure if this is a bug here or as a follow up to not crash when the
service is already there.

[frankban, 2013-09-13 14:07:50]

On 2013/09/13 13:45:00, rharding wrote:
> LGTM
> 
> Results of the script, first run:
> 
> http://paste.mitechie.com/show/1020/

Great, thank you for QAing this branch!

> I did run it a second time and got an error:
> 
> http://paste.mitechie.com/show/1021/
> 
> I'm not sure if this is a bug here or as a follow up to not crash when the
> service is already there.

Running the script a second time you also tested the validation 
step failing when there is a service name clash in the 
environment, and that's the correct behavior.
The subsequent KeyError is ok since the script expects
the request to be successful.

Thanks!

[bac, 2013-09-13 14:33:19]

LGTM

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....
server/guiserver/bundles/base.py:152: # cancelling scheduled jobs, even if the
job is the next to be started.
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.

[frankban, 2013-09-13 14:42:04]

*** 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....
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.