Runner now uses an interface, not a *HookContext; Flush is ~properly tested locally; Run* is ~properly tested by using the Context interface
consolidated yuckiness in HookContext.ActionData method
merge parent; address review; add SetProcess testing for runner
better var/field names
Fixed lp:1359714: JUJU_MACHINE_ID added to hook context
Merge pull request #1093 from dimitern/lp-1359714-juju-machine-id-for-charms

Fixed lp:1359714: JUJU_MACHINE_ID added to hook context

JUJU_MACHINE_ID is now available to charm hooks. It contains
the unit's assigned machine ID.
Fixed lp:1382709: openstack provider now returns SHUTOFF and SUSPENDED instances as well
Meter status support in metrics collector wire format.
Ignore conflict error when releasing maas nodes
Merge pull request #1094 from dimitern/lp-1382709-openstack-instance-shutoff-not-respected

Fixed lp:1382709: openstack provider now returns SHUTOFF and SUSPENDED instances as well

This fixes http://pad.lv/1382709. When an OpenStack instance
managed by Juju is manually stopped or suspended, its state
changes to SHUTOFF or SUSPENDED, respectively. Because the
openstack provider does not return details for instances
with states other than ACTIVE, BUILD, or BUILD(spawning),
the instance updater worker will fail to retrieve the status
of a manually stopped or suspended instance (there is a warning
in the log instead, which is misleading, as it says "unknown
instance id").

With this patch, instance updater will properly refresh the status
of such instances, after the LongPoll interval (15m) since the last
check has passed. Environ.Instances() for openstack will return
also instances with SHUTOFF or SUSPENDED state.

A quick drive-by fix was done for an annoying log spam at DEBUG
level about floating IP assigned to an instance.
Remove obsolete comment
merge parent
Merge pull request #1084 from fwereade/uniter-context-export-flush

Uniter context: export FlushContext

Most of the tests for finalizeContext, which is *complex* (not to mention complicated...) were invoking it by side-effect. So, it was really not well tested at all; to rectify this:

* context.Runner now uses a context.Context interface, not an explicit *HookContext
  * the finalizeContext method became FlushContext
  * the hookVars func became a HookVars method
  * the context ActionData method replaces an ad-hoc combination of similarly horrible access methods
* the various flush tests that depended on running a fake hook are now calling FlushContext directly; and slightly more than before, although (tbh) not *enough* by a long shot
* context.Runner.Run* methods are now tested using a mock context.Context, so we now have *actual tests* that the contexts get flushed
  * makeCharm/hookSpec now creates scripts in arbitrary dirs, so we can actually *test running an action* /grrmbl
Tweaked upgrade target selection

upgrades.PerformUpgrade() now takes all the upgrade targets for the
machine being upgraded instead of being called once per upgrade
target. This removes the possibility of upgrade steps being run twice,
simplifies the upgrade-steps worker and also ensures upgrade steps are
run in a more readily understood order.
Remove special casing for the databaseMaster upgrade target

Nows that upgrades.PerformUpgrade() is called once with all targets
for the machine being upgraded there is no need to treat
databaseMaster as a special case. The master state server now gets
two upgrade targets: stateServer and databaseMaster. This simplifies
the code and tests.
Merge pull request #1097 from mjs/upgrade-target-selection

Tweaked target selection

Tweaked upgrade target selection

upgrades.PerformUpgrade() now takes all the upgrade targets for the machine being upgraded instead of being called once per upgrade target. This removes the possibility of upgrade steps being run twice, simplifies the upgrade-steps worker and also ensures upgrade steps are run in a more readily understood order.

---

Remove special casing for the databaseMaster upgrade target

Nows that upgrades.PerformUpgrade() is called once with all targets for the machine being upgraded there is no need to treat databaseMaster as a special case. The master state server now gets two upgrade targets: stateServer and databaseMaster. This simplifies the code and tests.
Refactor InstanceBroker.StartInstance to return result struct

StartInstance will soon need to grow another result for
reporting back block devices allocated to a provisioned
instance. Rather than having to touch every bit of code
each time we expand the set, use a result struct.
Merge pull request #1100 from axw/environs-startinstanceresult

Refactor InstanceBroker.StartInstance to return result struct

StartInstance will soon need to grow another result for
reporting back block devices allocated to a provisioned
instance. Rather than having to touch every bit of code
each time we expand the set, use a result struct.
Comment update
Merge pull request #1095 from voidspace/maas-1381619

Ignore conflict error when releasing maas nodes

When releasing a node that is not in a releasable status, i.e. typically is already released, maas returns an error 409. Instead of dying and refusing to destroy environment we now ignore that error.

Error 409 is only used for a limited set of statuses, so this seems like safe behaviour. See: https://bugs.launchpad.net/maas/+bug/1381619/comments/15

Fixes bug 1381619.