Added setConfig functionality to the ECS.
Added heirarcical command execution.
Added tests for the next command functionality.
Added tests for the set_config functionality.
Remove class on controls when the user selects a config file for a deployed service
Added config file support to service config
Use saucy image for vagrant
Added tests for the config file upload in the service config inspector
Use NFS for vagrant file system sharing.

Also exports $HOME as /vagrant instead of the current project directory.
Fix vagrant build instructions
Merge pull request #192 from bac/vagrant-updates

Update vagrant to use saucy image.
Use NFS to mount host file system.
Set /vagrant to be user's $HOME for flexibility.
Change hacking instructions.
Merge pull request #191 from hatched/upload-1288450

### Notes
Create a config.yaml file with the following contents:
```
ceph:
  auth-supported: "foo"
```
### To QA
__Ghost Inspector__
- Drag and drop `ceph` from the charm browser
- Click the config file upload button and select the `config.yaml` file.
- The config options should disappear.
- Click to remove the file
- The config options should reappear.
- Click the config file upload button and select the `config.yaml` file.
- Deploy the charm.
- Change to the `settings` tab and the `auth-supported` value should read `foo`.

__Service Inspector__
- Deploy ceph
- Click the `settings` tab and then click to upload the `config.yaml` file.
- The config options should disappear.
- Click to remove the file
- The config options should reappear.
- Click the config file upload button and select the `config.yaml` file.
- Click `save changes`.
- The `auth-supported` value should now read `foo`.
Merge pull request #188 from hatched/esm-setconfig

This branch adds hierarchical command functionality to the ECS along with the set_config env method.

__To QA__
- Open the GUI using the `ecs` flag.
- Drag the liferay from the charmbrowser and click the deploy button once.
- Open the console and run `app.ecs.changeSet` and make note of the id (service-xxx).
- Run the following substituting the id with the appropriate one `app.ecs.setConfig('service-xxx', {'http-port': "80802"}, null, {'http-port': "8080"}, function() {});`.
- Run `app.ecs.changeSet` and there should now be two entries in the 'commands' array the second of which should have the method property set to 'set_config'.
Update machine model.

Include new info from the mega-watcher for machines.

QA:
- Bootstrap an ec2 environment with juju-core trunk (at least revno 2463):
  `juju bootstrap -e ec2 --upload-tools`.
- Deploy and expose the GUI:
  `juju deploy -e ec2 juju-gui && juju expose -e ec2 juju-gui`.
- Switch to this branch:
  `juju set -e ec2 juju-gui juju-gui-source="https://github.com/frankban/juju-gui.git machine-model-changes"`.
- Wait for the unit to be ready, log in and open the JS console.
- Check that two machines are present in the db:
  `app.db.machines.size();` --> 2.
- Inspect the GUI machine:
  `app.db.machines.getById('1');`.
- Check the returned fields, i.e. check that the machines properly includes:
  - four addresses (name is empty for now);
  - hardware characteristics (arch, cpuCores etc. in the hardware property);
  - jobs ('JobHostUnits');
  - life ('alive');
  - series ('precise');
  - supportedContainers ('lxc').
- Check that the bootstrap node also manages environments:
  `app.db.machines.getById('0').jobs;`
- Now create a new machine:
  `juju add-machine -e ec2 --series saucy`.
- And we have three machines:
  `app.db.machines.size();`.
- Check the new machine attributes multiple times:
  `app.db.machines.getById('2');`.
- You should see that supportedContainers is initially null, and then it will
  switch to ['lxc']. Also, series is 'saucy'.
- Let's add a container to machine 2:
  `juju add-machine -e ec2 lxc:2`.
- Retrieve information on the new container:
  `app.db.machines.getById('2/lxc/0');`
- You should see that initially hardware is an empty object and also
  supportedContainers is null.
- Wait until the container is fully provisioned (this can take a while):
  supportedContainers is an empty list and hardware include the architecture.
- Note that containers' addresses are not present because they are not
  returned by the cloud provider. The juju db also stores addresses returned
  by the machine itself. A change to juju-core is required if we find out
  we need to know LXC addresses.
- Done, destroy the environment, thank you!
Bug #1290312 - Add trash icon and click target.

The entire relation popover is no longer a click target. Instead there's
a trash icon which will trigger a remove function. Eventually the
service names in the relation will also become click targets to open
that service in the inspector.
Convert the changeSet data structure to a flat structure with key references to parent commands.
Merge pull request #195 from kadams54/relation-popover

Excellent. Thanks for the review! :shipit:
Merge pull request #194 from frankban/machine-model-changes

Include new info from the mega-watcher for machines.

QA:
- Bootstrap an ec2 environment with juju-core trunk (at least revno 2463):
  `juju bootstrap -e ec2 --upload-tools`.
- Deploy and expose the GUI:
  `juju deploy -e ec2 juju-gui && juju expose -e ec2 juju-gui`.
- Switch to this branch:
  `juju set -e ec2 juju-gui juju-gui-source="https://github.com/frankban/juju-gui.git machine-model-changes"`.
- Wait for the unit to be ready, log in and open the JS console.
- Check that two machines are present in the db:
  `app.db.machines.size();` --> 2.
- Inspect the GUI machine:
  `app.db.machines.getById('1');`.
- Check the returned fields, i.e. check that the machines properly includes:
  - four addresses (name is empty for now);
  - hardware characteristics (arch, cpuCores etc. in the hardware property);
  - jobs ('JobHostUnits');
  - life ('alive');
  - series ('precise');
  - supportedContainers ('lxc').
- Check that the bootstrap node also manages environments:
  `app.db.machines.getById('0').jobs;`
- Now create a new machine:
  `juju add-machine -e ec2 --series saucy`.
- And we have three machines:
  `app.db.machines.size();`.
- Check the new machine attributes multiple times:
  `app.db.machines.getById('2');`.
- You should see that supportedContainers is initially null, and then it will
  switch to ['lxc']. Also, series is 'saucy'.
- Let's add a container to machine 2:
  `juju add-machine -e ec2 lxc:2`.
- Retrieve information on the new container:
  `app.db.machines.getById('2/lxc/0');`
- You should see that initially hardware is an empty object and also
  supportedContainers is null.
- Wait until the container is fully provisioned (this can take a while):
  supportedContainers is an empty list and hardware include the architecture.
- Note that containers' addresses are not present because they are not
  returned by the cloud provider. The juju db also stores addresses returned
  by the machine itself. A change to juju-core is required if we find out
  we need to know LXC addresses.
- Done, destroy the environment, thank you!
Fixed tests fro the changeSet data structure conversion
Merge pull request #196 from hatched/ecs-flat-structure

This branch changes the changeSet data structure from a tree to a flat structure with reference to it's parents. At the moment it executes them top down but in follow-up branches I will implement the 'wait for parent' procedure.

#### To QA
- Load the GUI using the `ecs` flag
- Drag and drop ceph and click deploy once.
- Open the console and run `app.ecs.changeSet` and you should see a single record. Take note of the key name.
- Execute, substitute the previous key for the service name: `app.ecs.setConfig('service-xxx', {'http-port': "80802"}, null, {'http-port': "8080"}, function() {});`
- Run `app.ecs.changeSet` and you should now see two records.
- Run `app.ecs.commit()` and your charm should now be deployed.
Add the new environment header to allow switching between the service and machine views.
Merge pull request #193 from huwshimi/environment-header-view

This branch adds the new service/machine view header as see here: https://docs.google.com/a/canonical.com/file/d/0B5yaFXSrLF38aVk4ZXJZY0tJZWJTUy1GVXlScmZRS21rUFJv/edit

The contents of the header are still to be finalised and may well only contain the service/machine view links. As this is under a feature flag I figure we can finalise the contents in a follow-up branch.

The widget is being attached in app.js which won't be its final location, not sure if there is a better place for now.

When the machine view is implemented the sidebar won't be able to be minimised so the code to handle the header moving will go away.

The layout of the controls uses flexbox and I have tested that it works in Firefox, Chrome, IE10, IE11 and Safari. It would be good to QA that it works for others.