Add support for uncommitted bundles.

Add support for uncommitted bundles.

Introduce the -u/--uncommitted flag, which enables
uncommitted bundle support.

Improve output messages and tokens handling.

Also update jujubundlelib dep to latest version.

TESTS: 
`make fcheck` and wait a while for the functional tests
to complete.

QA:
- deploy bundles as usual:
  `devenv/bin/juju-quickstart mediawiki-single`;
- deploy uncommitted bundles:
  `devenv/bin/juju-quickstart -u u/openstack-charmers/openstack`;

https://code.launchpad.net/~frankban/juju-quickstart/uncommitted-bundles/+merge/261200

(do not edit description out of merge proposal)

[frankban, 2015-06-05 10:13:20]

Please take a look.

[rharding, 2015-06-05 12:28:42]

LGTM, I think most of my questions are answered in some way or another. I
understand that this is really checking is the version of the charm ready, not
the gui, so checking the version.js isn't a perfect match. I still can't help
but feel that the charm revision is tied to the gui release inside and maybe
it's a better overall solution to this. However, this is a perfectly reasonable
way to go about it and should work out most of the time.

https://codereview.appspot.com/247800043/diff/1/quickstart/app.py
File quickstart/app.py (right):

https://codereview.appspot.com/247800043/diff/1/quickstart/app.py#newcode659
quickstart/app.py:659: 'deployed Juju GUI charm ({}): requested bundle
deployment '
should we hint at a juju-gui upgrade here?

https://codereview.appspot.com/247800043/diff/1/quickstart/app.py#newcode663
quickstart/app.py:663: print('requesting uncommitted deployment of {} with the
following '
"uncommitted deployment" to "uncomitted loading"? deployment just strikes me as
very...deployed.

https://codereview.appspot.com/247800043/diff/1/quickstart/app.py#newcode679
quickstart/app.py:679: return response['Token']
does this open the gui url as it does when you just run juju-quickstart without
the deployment?

https://codereview.appspot.com/247800043/diff/1/quickstart/jujugui.py
File quickstart/jujugui.py (right):

https://codereview.appspot.com/247800043/diff/1/quickstart/jujugui.py#newcode62
quickstart/jujugui.py:62: def is_promulgated(reference):
I don't get this part. Can this not work if the gui you deployed is a local
deployment of the GUI? 

Should this better be a check for a flag/config/call to the GUI source instead?
Can it just check something like a check against version.js in some way?

https://codereview.appspot.com/247800043/diff/1/quickstart/jujutools.py
File quickstart/jujutools.py (right):

https://codereview.appspot.com/247800043/diff/1/quickstart/jujutools.py#newco...
quickstart/jujutools.py:60: if not jujugui.is_promulgated(charm_ref):
oic, so we assume. I still wonder about using version.js vs is_promulgated.

[frankban, 2015-06-05 13:15:32]

Please take a look.

https://codereview.appspot.com/247800043/diff/1/quickstart/app.py
File quickstart/app.py (right):

https://codereview.appspot.com/247800043/diff/1/quickstart/app.py#newcode659
quickstart/app.py:659: 'deployed Juju GUI charm ({}): requested bundle
deployment '
On 2015/06/05 12:28:41, rharding wrote:
> should we hint at a juju-gui upgrade here?

Good idea, done.

https://codereview.appspot.com/247800043/diff/1/quickstart/app.py#newcode663
quickstart/app.py:663: print('requesting uncommitted deployment of {} with the
following '
On 2015/06/05 12:28:41, rharding wrote:
> "uncommitted deployment" to "uncomitted loading"? deployment just strikes me
as
> very...deployed.

Done.

https://codereview.appspot.com/247800043/diff/1/quickstart/app.py#newcode679
quickstart/app.py:679: return response['Token']
On 2015/06/05 12:28:41, rharding wrote:
> does this open the gui url as it does when you just run juju-quickstart
without
> the deployment?

This token, if returned, is used to build the GUI URL.
Opening the GUI on the browser is done by manage.run.

https://codereview.appspot.com/247800043/diff/1/quickstart/jujutools.py
File quickstart/jujutools.py (right):

https://codereview.appspot.com/247800043/diff/1/quickstart/jujutools.py#newco...
quickstart/jujutools.py:60: if not jujugui.is_promulgated(charm_ref):
On 2015/06/05 12:28:42, rharding wrote:
> oic, so we assume. I still wonder about using version.js vs is_promulgated.

Well, some of the features we check (e.g. bundle deployment, uncommitted bundles
or new API endpoints) must be implemented principally on the server (because
qucikstart interacts mostly with the GUI server via its API), and that's why in
the cases we know the promulgated revision we can safely check for their
availability.
Given this is quickstart, I'd expect that we are dealing with promulgated GUI
charms 99% of the times, as you already mentioned. For the remaining cases we
trust the user and we expect her to be smart enough to handle possible (and
graceful) quickstart errors, which is the only bad thing that can happen if the
current customized charm does not support a requested feature.