lp:~frankban/juju-quickstart/jenv-env

Branch merges

Propose for merging

No branches dependent on this one.

Merged into lp:juju-quickstart at revision 107

Juju GUI Hackers: Pending requested 2014-12-15

Diff: 414 lines (+171/-44)

6 files modified

quickstart/app.py (+8/-8)
quickstart/manage.py (+6/-4)
quickstart/models/jenv.py (+69/-2)
quickstart/tests/models/test_jenv.py (+57/-4)
quickstart/tests/test_app.py (+26/-21)
quickstart/tests/test_manage.py (+5/-5)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

108. By Francesco Banconi on 2014-12-15

Connect to Juju using the user name.

107. By Francesco Banconi on 2014-12-15

Implement the jenv._get_value_from_yaml helper function.

106. By Francesco Banconi on 2014-11-13

Add support for the manual provider.

Also reorder the provider fields so
that required ones come first.
The hope for this is to improve the
user experience while creating
environments.

Tests: `make check`.

QA: use quickstart as usual to set up
environments.
To test the manual provider, I've done
the following:

- I used a separate vmware virtual machine:
  let's assume its address is 192.168.1.5.
- Install the SSH server in the vm:
        `sudo apt-get install ssh`.
- Copy your ssh credential over:
        `scp -rp ~/.ssh 192.168.1.5:~`.
- Allow sudo power without password for your user on the vm, by
  editing the /etc/sudoers file and adding the following:
        $USER ALL=(ALL) NOPASSWD: ALL
  where $USER is your user name.
- Run `.venv/bin/python juju-quickstart -i`, select the option to
  create a new "Manual Provisioning" environment, select a name for it and
  use the vm address as the "bootstrap host", save the environment
  and then run it!
- wait for the environment to be ready, then run quickstart again
  with the same environment to check it recognizes it's
  already bootstrapped.
Done, thank you!

R=rharding, matthew.scott
CC=
https://codereview.appspot.com/172410043

105. By Francesco Banconi on 2014-11-12

New bootstrap strategy.

This is a massive branch: my apologies.
But:
    - a new module has been created (netutils), so there
      are license headers and moreover some existing
      functions (with their tests) have been just moved
      from utils.py and must not be re-reviewed.
      The only new function there is check_listening.
    - most of the code are tests: we reached 700 unit
      tests yay!

This branch changes the way quickstart is run on an
existing environment: instead of always trying to
bootstrap, it looks for the jenv file for the current
environment, and, if present, it retrieves the API URL
from there. As a consequence, quickstart uses Juju
in a less expensive way, and it's also faster when
invoked on a bootstrapped environment.

Split the app.bootstrap function to two new
functions: app.bootstrap and app.status. The intent
is to make them more reusable and more easy to test.

Fix a subtle bug never reported and not easy to hit:
the environment type of an existing environment is
now retrieved from the jenv, rather than relying on
what's stored in the environments.yaml file.

Also reorganized the tests for manage.run: over
time they ended up failing to achieve their goal
of describing how the application is run, and
become not really easy to update and change.
Now this situation should be improved.

The little change to the HACKING file is to make
the rst to render correctly on sublime text.

Tests: `make check`.

QA: run quickstart as usual on local and ec2.
Run quickstart again on an already bootstrapped
environment (local and ec2). You should no longer
see the "bootstrapping environment" message.
Instead, a more correct "reusing the already
bootstrapped..." message is displayed.
Also this should feel quicker, especially on ec2.

Thank you!

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

104. By Francesco Banconi on 2014-11-11

Code reorganization + docs.

Reorganize the jenv related code in preparation of the
bootstrap strategy change.

Separate jenv handling from the environments.yaml file
management in models.

As a consequence of only supporting juju >= 1.18 we
can now safely always retrieve the admin-secret from
the jenv file.

Also updated the HACKING docs to include a brief
description of the project structure.

Tests: `make check`.

QA: use quickstart as usual.

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

103. By Francesco Banconi on 2014-11-10

Unit address from the machines watcher only

Only use the mega-watcher for machines to retrieve
the Juju GUI unit address.
This change has several consequences:
- it allows us to apply some logic on how the
  right address is chosen. For instance, now
  we try to resolve public hostnames before
  proceeding, and this should fix the cases
  where a cloud dns is not configured on the
  machine running quickstart. This is the case
  of many maas environments;
- it simplifies parsing the mega-watcher changes;
- more importantly, it breaks compatibility
  with very old versions of juju (<1.18), in which
  the mega-watcher for machines did not include
  machine addresses.

For this reason, quickstart now explicitly
drops support for juju < 1.18.1
(1.18.1 is the version on trusty universe).

This also allows for removing some version
checks in the code, including sudo handling when
calling bootstrap on local envs, several special
cases on the watcher side, and other oddities.

For the reasons above, I bumped the quickstart
version up to 1.5.0.

PS: my apologies for the long diff, hope the code
is still easy to follow. Sorry.

Tests: `make check`

QA:
run quickstart as usual, on local and cloud envs,
check it works properly when run again, etc.
this branch has been already successfully QAed in
a maas environment by Adam (Landscape team).

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

102. By Francesco Banconi on 2014-11-10

Do not hide errors on interactive session.

R=jay.wren, bac
CC=
https://codereview.appspot.com/166420044

101. By Francesco Banconi on 2014-10-10

Support automatic detection of a logged in MAAS.

Automatically detect a logged in MAAS API, so that
it is possible to use the stored credentials to
create and bootstrap a MAAS environment without
user intervention.

QA:
- ssh to the GUI MAAS;
- destroy the existing environment;
- remove the ~/.juju directory;
- use the MAAS UI (http://maas.jujugui.org/MAAS/nodes/)
  to release the nodes if they are not in a ready state;
- this branch is already checked out in ~/juju-quickstart/sandbox/;
- start quickstart from there:
  cd ~/juju-quickstart/sandbox/ && .venv/bin/python juju-quickstart
- quickstart should show the option to automatically create and
  bootstrap the MAAS environment;
- select the option and wait for the envirnment to be ready:
  this can fail due to juju/maas interaction problems we currently
  have, retrying the process should eventually succeed.

Done, thank you!

R=bac, jay.wren
CC=
https://codereview.appspot.com/157830043

100. By Francesco Banconi on 2014-10-01

Add MAAS support to quickstart.

Also bump version up and update tge default
Juju GUI charm URLs used when charmworld cannot
be contacted.

Tests: `make check`.

QA: already done on a live MAAS instance.
However, it is possible to just try to create
a MAAS environment YAML via the interactive
session.

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

99. By Francesco Banconi on 2014-09-11

Bump version up for 1.4.3 release.

R=
CC=
https://codereview.appspot.com/135700043