Created local charm new or upgrade inspector.
AddMachines and DestroyMachines API calls.
Merge pull request #148 from frankban/machines-api

AddMachines and DestroyMachines API calls.

Implement the machine related API calls.

QA:

Bootstrap an ec2 environment using juju-core trunk
(creating lxc inside lxc did not work in my saucy machine,
and also note core trunk does not support kvm at this time):
  juju bootstrap -e ec2 --upload-tools

Deploy and expose the GUI:
  juju deploy -e ec2 juju-gui --to 0
  juju expose -e ec2 juju-gui

Enable the GUI console and switch to the current branch:
  juju set -e ec2 juju-gui juju-gui-console-enabled=true juju-gui-source="https://github.com/frankban/juju-gui.git machines-api"

When the GUI is ready, log in and open the JavaScript console.

Define the following callback that will help visualizing
the data returned by the API calls:
  var callback = function(data) {console.log(data)};

Add two new machines, the first having the default series,
the second being a saucy one:
  app.env.addMachines([{}, {series: 'saucy'}], callback);

With `juju status -e ec2` you should see the two new machines
being created. Check the series is what you specified,
and check the names in the JS response is what's expected.

Make an invalid call to ensure juju-core errors are
properly reported:
    app.env.addMachines([{series: true}], callback);

Call addMachines without passing params, to ensure
the call is stopped before hitting the server:
    app.env.addMachines([], callback);

Now let's create containers. Create one lxc in machine
2 and a another one in a new machine:
    app.env.addMachines([{containerType: 'lxc', parentId: '2'}, {containerType: 'lxc'}], callback);
The response should contain a machines array with including
"2/lxc/0" and "3/lxc/0" names.

Destroy machine 1 and 3:
    app.env.destroyMachines(['1', '3'], false, callback);
You should see an error:
some machines were not destroyed: machine 3 is hosting containers "3/lxc/0";
Machine 1 should be gone.

Try harder to destroy machine 3:
    app.env.destroyMachines(['3'], true, callback);
This time machine 3 should correctly be removed.

Destroy the lxc on machine 2:
    app.env.destroyMachines(['2/lxc/0'], false, callback);

Let's create two new containers on machine 2,
this time with a different series:
    app.env.addMachines([{containerType: 'lxc', parentId: '2', series: 'raring'}, {containerType: 'lxc', parentId: '2', series: 'quantal'}], callback);
Check everything is ok.

Finally, let's create a new machine with four cores:
    app.env.addMachines([{constraints: {'cpu-cores': 4}}], callback);
Check the machine 4 with four cores is being created.

Done, destroy the environment, thank you!
Fix local charm deployed twice in sandbox.
Merge pull request #149 from frankban/bug-1285223

Fix local charm deployed twice in sandbox.
Handle the case when the charm already exists in the charms db.
No QA required.
Refactored local charm upload helpers to support multiple service upgrades
Merge pull request #150 from hatched/upgrade-new-inspector

__To QA__
- Deploy a local charm to sandbox
- Navigate around the inspector, opening closing, viewing charm details etc (exploratory)
- Drag and drop the same local charm zip
- You should get an inspector that has the Request Series view on top and the new Upgrade Services view on the bottom.

__Notes__
Part 3 will hook up the upgrade. It needed the fakebackend fix to land first.
Update HACKING with update git aliases.
Selecting to upgrade a service in the local charm upgrade inspector upgrades the services charm
Merge pull request #151 from mitechie/update-git-docs

- Update the fetch-pr alias per suggestion from Gary to add the +ref.
- Rename the juju-sync to sync-juju to start the trend of available sync-* commands
- Add a sync-trunk which will do a rebase from your develop branch.
- Update docs on how to keep your feature branch up to date based on the latest upstream trunk.
Ability to deploy units to specific machines.
Update push command for git 1.9
Merge pull request #154 from mitechie/update-push-docs
added tests for the local charm upgrade functionality
Merge pull request #152 from frankban/add-to-machine-spec

Ability to deploy units to specific machines.

Support ToMachineSpec in goenv backend 
ServiceDeploy and AddServiceUnits calls.

Also update the pyenv for compatibility.

Drive by fix to code indentation/style.

QA:

Ensure the sandbox mode works well:
- make prod;
- deploy a service, add units, check
  everything is fine.

Live test the functionality on an ec2
environment:
- juju bootstrap -e ec2 --upload-tools
- juju deploy -e ec2 juju-gui --to 0
- juju expose -e ec2 juju-gui
- juju set -e ec2 juju-gui juju-gui-console-enabled=true juju-gui-source="https://github.com/frankban/juju-gui.git add-to-machine-spec"
- when the GUI is ready, log in, open the JS console;
- deploy a new service (e.g. mysql) as usual dragging the badge from
  the browser. This is done to ensure the usual way to deploy services
  from the GUI still works well: a new machine should be created to host
  mysql;
- add another unit to mysql using the inspector: at this point you should have
  mysql deploying to machines "1" and "2"
- using the console add a new machine, another new machine including an LXC
  container, and a new LXC on machine "1":
  app.env.addMachines([{}, {containerType: 'lxc'}, {containerType: 'lxc', parentId: '1'}]);
- use `juju status -e ec2` to ensure the new machines/containers have been 
  created: machine "3" and "4", containers "4/lxc/0" and "1/lxc/0"
- deploy wordpress to "1/lxc/0" by running the following:
  app.env.deploy('cs:precise/wordpress-21', 'wordpress', null, null, 1, null, '1/lxc/0');
- add another unit to wordpress, placing it on machine "3":
  app.env.add_unit('wordpress', 1, '3');
- define the following callback that will help visualizing
  the data returned by the API calls:
  var callback = function(data) {console.log(data)};
- ensure an error is returned when trying to deploy multiple units on
  the same machine:
  app.env.deploy('cs:precise/haproxy-27', 'ha', null, null, 3, null, '4/lxc/0', callback);
- deploy haproxy to machine "4" and container "4/lxc/0":
  app.env.deploy('cs:precise/haproxy-27', 'ha', null, null, 1, null, '4', callback);
  app.env.add_unit('ha', 1, '4/lxc/0');

Done, destroy your environment, thank you!
Merge pull request #153 from hatched/upgrade-from-local-charm

To QA
--------
**Use real env (ec2, lxc)**
- Deploy a local charm
- Drag the same local charm to the canvas, an inspector which gives you the option to upload or upgrade should come up
- Upload and deploy another version of the charm (so you now have two services with the same charm)
- Wait for both to come up.
- View the inspector for both services and take note of the charm url. One should be a higher version than the other.
- Drag the same local charm to the canvas and select a single service to upgrade.
- Wait 10s or so
- Click that services inspector and it should have a different charm url now.
Export constraints as a space-separated list.
Added integration tests for the local charm helper utils
Merge pull request #155 from bac/constraint-export

Make exported bundles write constraints as space-separated.

The fakebackend is changed to accept either the older comma-separated constraints or space-separated.
Merge pull request #156 from hatched/local-upgrade-tests

No QA needed, if it passes CI it's A-OK