Comment 1 for bug 1490865

I've reproduced this on trusty with maas 1.8.

Here's what I did:

1. spin up two hosts on maas
2. sign into one of them
3. write out a valid environments.yaml with a 'maas' env with valid maas api key and ip. (via the openstack installer packaging)
4. attempt a bootstrap that fails (in the bug it failed because juju wasn't installed, but it's also sufficient to bootstrap --to nonexistent-system.isnt.in.maas
5. 'juju destroy-environment maas' fails reasonably with an error message that it can't connect to the (juju) API because env isn't bootstrapped.
6. 'juju destroy-environment --force maas ' issues these requests to the MAAS API:

- 172.16.0.61 - - [01/Sep/2015:13:40:37 -0400] "GET /MAAS/api/1.0/nodes/?agent_name=&op=list HTTP/1.1" 200 1563 "-" "Go 1.1 package http"
- 172.16.0.61 - - [01/Sep/2015:13:40:37 -0400] "POST /MAAS/api/1.0/nodes/?op=release HTTP/1.1" 200 355 "-" "Go 1.1 package http"

7. and now everything I owned in maas is now released - including the system I was running the juju client on, and the other system I deployed, neither of which were created by juju.

I think that juju should check if agent_name is set to "" and avoid releasing in that case. Since it is set when bootstrap succeeds, it appears reasonable to assume that if agent_name isn't set, there's no way to safely only destroy things juju started so it should bail.