Merge lp:~frankban/juju-quickstart/uncommitted-bundles into lp:juju-quickstart
| Status: | Merged |
|---|---|
| Merged at revision: | 135 |
| Proposed branch: | lp:~frankban/juju-quickstart/uncommitted-bundles |
| Merge into: | lp:juju-quickstart |
| Diff against target: |
665 lines (+332/-57) 13 files modified
quickstart/__init__.py (+1/-1) quickstart/app.py (+62/-6) quickstart/juju.py (+9/-0) quickstart/jujugui.py (+28/-0) quickstart/jujutools.py (+2/-5) quickstart/manage.py (+31/-21) quickstart/settings.py (+7/-2) quickstart/tests/functional/test_functional.py (+8/-0) quickstart/tests/test_app.py (+99/-16) quickstart/tests/test_juju.py (+12/-0) quickstart/tests/test_jujugui.py (+46/-0) quickstart/tests/test_manage.py (+23/-2) tox.ini (+4/-4) |
| To merge this branch: | bzr merge lp:~frankban/juju-quickstart/uncommitted-bundles |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Brad Crittenden (community) | code + qa | 2015-06-05 | Approve on 2015-06-08 |
|
Review via email:
|
|||
Commit Message
Add support for uncommitted bundles.
Description of the Change
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/
- deploy uncommitted bundles:
`devenv/
| Francesco Banconi (frankban) wrote : | # |
| Richard Harding (rharding) wrote : | # |
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:/
File quickstart/app.py (right):
https:/
quickstart/
deployment '
should we hint at a juju-gui upgrade here?
https:/
quickstart/
with the following '
"uncommitted deployment" to "uncomitted loading"? deployment just
strikes me as very...deployed.
https:/
quickstart/
does this open the gui url as it does when you just run juju-quickstart
without the deployment?
https:/
File quickstart/
https:/
quickstart/
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:/
File quickstart/
https:/
quickstart/
oic, so we assume. I still wonder about using version.js vs
is_promulgated.
- 145. By Francesco Banconi on 2015-06-05
-
Changes as per review.
| Francesco Banconi (frankban) wrote : | # |
Please take a look.
https:/
File quickstart/app.py (right):
https:/
quickstart/
deployment '
On 2015/06/05 12:28:41, rharding wrote:
> should we hint at a juju-gui upgrade here?
Good idea, done.
https:/
quickstart/
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:/
quickstart/
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:/
File quickstart/
https:/
quickstart/
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.
| Brad Crittenden (bac) wrote : | # |
Francesco I can no longer log in to Rietveld so I'm making comments here only.
The code looks good. I'll do QA now.

Reviewers: mp+261200_ code.launchpad. net,
Message:
Please take a look.
Description:
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: bin/juju- quickstart mediawiki-single`; bin/juju- quickstart -u u/openstack- charmers/ openstack` ;
- deploy bundles as usual:
`devenv/
- deploy uncommitted bundles:
`devenv/
https:/ /code.launchpad .net/~frankban/ juju-quickstart /uncommitted- bundles/ +merge/ 261200
(do not edit description out of merge proposal)
Please review this at https:/ /codereview. appspot. com/247800043/
Affected files (+329, -57 lines): __init_ _.py jujugui. py jujutools. py manage. py settings. py tests/functiona l/test_ functional. py tests/test_ app.py tests/test_ juju.py tests/test_ jujugui. py tests/test_ manage. py
A [revision details]
M quickstart/
M quickstart/app.py
M quickstart/juju.py
M quickstart/
M quickstart/
M quickstart/
M quickstart/
M quickstart/
M quickstart/
M quickstart/
M quickstart/
M quickstart/
M tox.ini