Integrate the env management functionality.

Integrate the env management functionality.

This branch enables the environment management
Urwid interactive session feature in quickstart,
but also includes some other improvements, described
below.

Exposed a way to let the user quickly
create and bootstrap a local env if no environments
are already configured. This is implemented
adding a closure (create_and_start_local_env) to the
env_index view: this could have been implemented
as a separate function as well (more easily testable,
less surprising), but I decided to stick with the
pattern used by the other views for now.

Changed the env_edit view so that the first created
environment is automatically set as default.

Renamed manage._validate_env to manage._setup_env:
the function now does a lot more than validation, e.g.
it lunches the interactive session, handles the
case when the Juju home is not yet configured, etc.
This function also sets up a save_callable to be used
by views. I could have used partial to create such a
function, but I decided to implement a HO
_create_save_callable that can be easily be extended
later in order to enable the backup functionality.

Bumped version up.

The diff is very long, my apologies, but you can safely
ignore deleted code:
- the demo application, no longer required;
- the ensure_environments function + its tests;
- envs.parse_env_file + its tests (
  replaced by envs.load + envs.validate).
Moreover, the env_type_db definition in
quickstart.models.envs is just a copy/paste replacement
of the original one: the only difference is that
an ordered dict is used in place of the usual dict.
This change has been introduced so that views
can list the supported environment types in the order
they are defined.

Tests: `make check`.

QA: if you have time, given the amount of code
enabled by this branch, and given the differences
in each one Juju configuration, I'd appreciate both
reviewers to QA the interactive session.
The instructions follow, thank you very much!

- Run `make`.

- Backup your Juju home:
  `mv ~/.juju ~/juju-home-backup`
  This way we can simulate Juju is not configured at all.

- Run `.venv/bin/python juju-quickstart`.
  Quickstart should welcome you and propose, among
  other things, to automatically create and bootstrap
  a local environment. Do that, provide your sudo
  password if requested, wait until the process completes
  and the GUI opens in your default browser as usual.
  This can take several minutes based on the sanity of your
  LXC configuration. Before opening the browser, you should
  see instructions on re-running quickstart to reopen
  and log in to the GUI later or restarting the interactive
  session. Also note that an admin password has been
  automatically generated and printed to stdout.

- Run `.venv/bin/python juju-quickstart`.
  This time no interactive session is started, the application
  recognizes the environment is already bootstrapped and
  quickly reopens the browser and logs in to the GUI.

- Run `cat ~/.juju/environments.yaml`.
  Check the generated environment file looks sane.

- Destroy the local environment:
  `sudo juju destroy-environment -e local -y`

- Run `.venv/bin/python juju-quickstart -i`.
  The interactive session should start and this time
  it should list your existing environment.
  Let's customize the local one: click on it, then
  on the "edit" button, and then use the form
  to change its name (e.g. replace "local" with "lxc").
  Hit page-down and click "save" an then "back" to
  return to the index view.
  Now let's create an ec2 environment by selecting
  "new ec2 environment". Call it "aws", auto-generate
  the admin-secret and the control-bucket, fill in your
  ec2 credentials and save the new environment.
  Also make it the default one, either by using the
  checkbox in the form or by clicking "set default"
  from the env details view. From the envs detail view,
  let's go ahead and bootstrap the "aws" env by clicking "use".
  As above, wait for the ec2 environment to be bootstrapped
  and the GUI opened. In the meanwhile, you can run
  `cat ~/.juju/environments.yaml` in another terminal to
  ensure the env file looks good. Note that at this time
  no backup files are created: this is the goal of my next card.

- Run `juju switch` to check that the default environment
  is now "aws".

- Check that command line options validation still work: all the
  following command should exit with pertinent errors:

  .venv/bin/python juju-quickstart --gui-charm-url invalid

  .venv/bin/python juju-quickstart --gui-charm-url http:~juju-gui/precise/juju-gui-80

  .venv/bin/python juju-quickstart --gui-charm-url cs:precise/juju-gui-1 bundle:~jorge/mediawiki-simple/4/mediawiki-simple

  .venv/bin/python juju-quickstart --gui-charm-url cs:saucy/juju-gui-80

  .venv/bin/python juju-quickstart -e no-such

  .venv/bin/python juju-quickstart /no-such-bundle

  .venv/bin/python juju-quickstart bundle:~jorge/mediawiki-simple/4/no-such

- Let's also try to deploy a bundle:
  run `juju unexpose juju-gui` and then
  `.venv/bin/python juju-quickstart bundle:~jorge/mediawiki-simple/4/mediawiki-simple`.
  The service should be re-exposed by quickstart and the bundle
  deployment should start as usual.

- Destroy the ec2 environment: `juju destroy-environment -e aws -y`.

- Restore your existing juju home:
  `rm -rf ~/.juju && mv ~/juju-home-backup .juju`.

- Create a backup copy of your environments file:
  `cp ~/.juju/environments.yaml ~/environments.yaml.bak`.

- Not it's time to be creative. Run quickstart in interactive
  mode (`.venv/bin/python juju-quickstart -i`): you should
  see your environments listed.
  Start changing/removing/creating/bootstrapping your
  environments. Remove required fields, exit without editing
  to check your environments file is not saved by quickstart
  if not necessary, try to create two envs with the same name.
  In a sentence: try hard to break the application in any
  way you can imagine.

- Once done, restore your original environments file:
  `mv ~/environments.yaml.bak ~/.juju/environments.yaml`.

- Remember to destroy all the environments you
  bootstrapped.

Done! Many thanks for going through all these QA steps.

https://code.launchpad.net/~frankban/juju-quickstart/enable-env-management/+merge/201163

(do not edit description out of merge proposal)

[frankban, 2014-01-10 11:16:16]

Please take a look.

[benji-york, 2014-01-10 18:05:45]

LGTM with one tiny suggestion.

https://codereview.appspot.com/50430043/diff/1/quickstart/manage.py
File quickstart/manage.py (right):

https://codereview.appspot.com/50430043/diff/1/quickstart/manage.py#newcode211
quickstart/manage.py:211: options.interactive = interactive
This function has gotten a bit big.  I wonder if a nice refactoring would be one
that made this function contain no conditionals but instead called four or five
subfunctions.

[rharding, 2014-01-10 18:11:01]

code looks good, will start QA.

[rharding, 2014-01-10 19:52:17]

QA ok, LGTM

It was cool to use it in interactive mode against my original environments.yaml
file. The only issue from a user POV was I was looking for some command to
save/write the changes made. When I ended up just quitting I saw the output 

changes to the environments file have been saved

but it'd be nice to have some sort of feedback or specific 'save' command in the
UI.

[frankban, 2014-01-13 15:38:30]

*** Submitted:

Integrate the env management functionality.

This branch enables the environment management
Urwid interactive session feature in quickstart,
but also includes some other improvements, described
below.

Exposed a way to let the user quickly
create and bootstrap a local env if no environments
are already configured. This is implemented
adding a closure (create_and_start_local_env) to the
env_index view: this could have been implemented
as a separate function as well (more easily testable,
less surprising), but I decided to stick with the
pattern used by the other views for now.

Changed the env_edit view so that the first created
environment is automatically set as default.

Renamed manage._validate_env to manage._setup_env:
the function now does a lot more than validation, e.g.
it lunches the interactive session, handles the
case when the Juju home is not yet configured, etc.
This function also sets up a save_callable to be used
by views. I could have used partial to create such a
function, but I decided to implement a HO
_create_save_callable that can be easily be extended
later in order to enable the backup functionality.

Bumped version up.

The diff is very long, my apologies, but you can safely
ignore deleted code:
- the demo application, no longer required;
- the ensure_environments function + its tests;
- envs.parse_env_file + its tests (
  replaced by envs.load + envs.validate).
Moreover, the env_type_db definition in
quickstart.models.envs is just a copy/paste replacement
of the original one: the only difference is that
an ordered dict is used in place of the usual dict.
This change has been introduced so that views
can list the supported environment types in the order
they are defined.

Tests: `make check`.

QA: if you have time, given the amount of code
enabled by this branch, and given the differences
in each one Juju configuration, I'd appreciate both
reviewers to QA the interactive session.
The instructions follow, thank you very much!

- Run `make`.

- Backup your Juju home:
  `mv ~/.juju ~/juju-home-backup`
  This way we can simulate Juju is not configured at all.

- Run `.venv/bin/python juju-quickstart`.
  Quickstart should welcome you and propose, among
  other things, to automatically create and bootstrap
  a local environment. Do that, provide your sudo
  password if requested, wait until the process completes
  and the GUI opens in your default browser as usual.
  This can take several minutes based on the sanity of your
  LXC configuration. Before opening the browser, you should
  see instructions on re-running quickstart to reopen
  and log in to the GUI later or restarting the interactive
  session. Also note that an admin password has been
  automatically generated and printed to stdout.

- Run `.venv/bin/python juju-quickstart`.
  This time no interactive session is started, the application
  recognizes the environment is already bootstrapped and
  quickly reopens the browser and logs in to the GUI.

- Run `cat ~/.juju/environments.yaml`.
  Check the generated environment file looks sane.

- Destroy the local environment:
  `sudo juju destroy-environment -e local -y`

- Run `.venv/bin/python juju-quickstart -i`.
  The interactive session should start and this time
  it should list your existing environment.
  Let's customize the local one: click on it, then
  on the "edit" button, and then use the form
  to change its name (e.g. replace "local" with "lxc").
  Hit page-down and click "save" an then "back" to
  return to the index view.
  Now let's create an ec2 environment by selecting
  "new ec2 environment". Call it "aws", auto-generate
  the admin-secret and the control-bucket, fill in your
  ec2 credentials and save the new environment.
  Also make it the default one, either by using the
  checkbox in the form or by clicking "set default"
  from the env details view. From the envs detail view,
  let's go ahead and bootstrap the "aws" env by clicking "use".
  As above, wait for the ec2 environment to be bootstrapped
  and the GUI opened. In the meanwhile, you can run
  `cat ~/.juju/environments.yaml` in another terminal to
  ensure the env file looks good. Note that at this time
  no backup files are created: this is the goal of my next card.

- Run `juju switch` to check that the default environment
  is now "aws".

- Check that command line options validation still work: all the
  following command should exit with pertinent errors:

  .venv/bin/python juju-quickstart --gui-charm-url invalid

  .venv/bin/python juju-quickstart --gui-charm-url
http:~juju-gui/precise/juju-gui-80

  .venv/bin/python juju-quickstart --gui-charm-url cs:precise/juju-gui-1
bundle:~jorge/mediawiki-simple/4/mediawiki-simple

  .venv/bin/python juju-quickstart --gui-charm-url cs:saucy/juju-gui-80

  .venv/bin/python juju-quickstart -e no-such

  .venv/bin/python juju-quickstart /no-such-bundle

  .venv/bin/python juju-quickstart bundle:~jorge/mediawiki-simple/4/no-such

- Let's also try to deploy a bundle:
  run `juju unexpose juju-gui` and then
  `.venv/bin/python juju-quickstart
bundle:~jorge/mediawiki-simple/4/mediawiki-simple`.
  The service should be re-exposed by quickstart and the bundle
  deployment should start as usual.

- Destroy the ec2 environment: `juju destroy-environment -e aws -y`.

- Restore your existing juju home:
  `rm -rf ~/.juju && mv ~/juju-home-backup .juju`.

- Create a backup copy of your environments file:
  `cp ~/.juju/environments.yaml ~/environments.yaml.bak`.

- Not it's time to be creative. Run quickstart in interactive
  mode (`.venv/bin/python juju-quickstart -i`): you should
  see your environments listed.
  Start changing/removing/creating/bootstrapping your
  environments. Remove required fields, exit without editing
  to check your environments file is not saved by quickstart
  if not necessary, try to create two envs with the same name.
  In a sentence: try hard to break the application in any
  way you can imagine.

- Once done, restore your original environments file:
  `mv ~/environments.yaml.bak ~/.juju/environments.yaml`.

- Remember to destroy all the environments you
  bootstrapped.

Done! Many thanks for going through all these QA steps.

R=benji1, rharding
CC=
https://codereview.appspot.com/50430043

[frankban, 2014-01-13 16:02:02]

On 2014/01/10 18:05:45, benji1 wrote:
> LGTM with one tiny suggestion.
> 
> https://codereview.appspot.com/50430043/diff/1/quickstart/manage.py
> File quickstart/manage.py (right):
> 
> https://codereview.appspot.com/50430043/diff/1/quickstart/manage.py#newcode211
> quickstart/manage.py:211: options.interactive = interactive
> This function has gotten a bit big.  I wonder if a nice refactoring would be
one
> that made this function contain no conditionals but instead called four or
five
> subfunctions.

Done. Thank you both!