Comment 8 for bug 1611453

> After discussion we Curtis, we believe the test is correct. If we could install juju over SSH, we should be able to remove it over SSH.

I'll repeat what we discussed in Barcelona, hopefully it will ring a bell.

kill-controller is effectively the same as the old "destroy-environment --force", with a (IMO misguided) attempt to do the destruction "safely" via the API first. So you can think of kill-controller as "destroy-environment || destroy-environment --force".

Now, *IF* Juju can connect to the API then all will be well. The knowledge of manual machines is defined in the controller -- *only* in the controller -- so talking to the controller to clean up means that the knowledge of those manual machines is accessible.

In the fallback case, Juju is doing everything from the client side. The client is not necessarily the same one that added the manual machines. There is no knowledge of them at the client; it is all within the controller. This is unlike cloud providers, where the client can communicate directly with the cloud to identify resources related to the controller. There is nowhere to go, except the controller, which is inaccessible (or the code path wouldn't be taken).

I hope that clarifies things.