destroy-environment no longer removes .jenv

[Chris Glass]

Running "juju destroy-enviornment" when using the null provider and other providers does not delete the ~/.juju/environments/null.jenv file. This results in user confusion when for example a failure was due to an incorrect configuration.

Steps to reproduce:

1. Install a fresh ubuntu server inside a KVM to use as a bootstrap node.
2. run "juju init; juju switch null"
3. edit ~/.juju/environments.yaml, add the KVM's IP address in the null provider's "bootstrap-host" entry. Make a typo.
4. run "juju bootstrap". Since step 3 introduced a typo, the environment fails to bootstrap.
5. correct the typo.
6. Run "juju destroy-environment"
7. Run "juju bootstrap" again.

What happens:
The first Ip address entered is used in all subsequent bootstraps. Juju destroy-environment 's behavior is not consistent with other providers implementations.

What was expected:
The juju destroy-environment command should remove the ~/.juju/environments/null.jenv file. This would make a subsequent environment creation regenerate that file, therefore allowing for a successful deployement. Similarly, a call to "destroy-environment" for other providers allows to correct provider configuration mistake.

Subjective comment:
It is reasonable to assume that "juju destroy-environment" resets juju's knowledge of the environment.

ADDENDUM
This affects several providers

[Roger Peppe (rogpeppe)]

[I'm going to assume that the destroy-environment command
above printed an error message and failed - if not, my assumptions
are faulty and there's another problem going on that I have not
identified]

I think there are at least two issues going on here:

Firstly: if the bootstrap fails and the .jenv file has been
created as a result of bootstrapping, it's not removed.
I think it should.

Secondly: if destroy-environment fails to talk to the
provider, the .jenv file is not removed. This is more arguable.
It may be that the error is transient, and that running
destroy-environment again may succeed. In that
case, do we really want to destroy the .jenv file,
which may be our only handle on the environment,
including references to resources that need to be cleaned up?

To solve the second issue, perhaps we should have a --force
flag on destroy-environment which forces removal of the
.jenv file even if we cannot talk to the environment That is
slightly awkward though, as we already have a --yes flag which could
be construed as similar.

As another passing thought, we could potentially have a
"juju forget-environment" command that just removes the .jenv file without attempting
to destroy the environment. When people are passing .jenv
files around a lot, perhaps this might make sense. I'm
not keen currently though.

[Chris Glass (tribaal)]

The bootstrap didn't fail - it did create a working .jenv.

You are correct, "juju destroy-environment" results in the following error:
ERROR null provider destruction is not implemented yet

The point I'm trying to make is that the implementation of "destroy-environment" for the null provider should be to remove the .jenv entry in all cases.
"destroy-environment" should do what it says on the can - destroy :) In the case of the null provider, there's nothing else to destroy than the .jenv entry...

Sidenote: Why would people pass .jenv files around? I don't see a usecase for that.

[Andrew Wilkins (axwalk)]

@tribaal: Sorry I didn't respond sooner, this bug escaped my attention.

destroy-environment for null/manual provider will (when implemented - soon!) remove the Juju agents from all machines in the environment. After it does that, it will also remove the .jenv file.

[Andrew Wilkins (axwalk)]

I'm working on a version of destroy-environment that takes care of manual environments now.