Cannot destroy-environment with 'juju user add' .jenv file

This issue may relate to bug 1334768 which implies juju does not handle several scenarios correctly when environments.yaml doesn't have an entry for the env.

Hmm... I see what the problem is here.

This is a hangover from the old world. We are almost certainly going to have to add a limitation such that the state server environment can only be destroyed by the creator, as it needs access to the config in order to be able to force destroy if necessary.

Also force should not be an option for any environment except the state server environment.

This isn't a stop-the-line issue, but it is important.

I followed the steps and tested locally: created environ "env1" and added user "bob" to it. At this point I had two jenv files pointing to the same environment: bob.jenv and env1.jenv. Then I called "juju destroy-environment bob". This removed the bob.jenv file and the environment record from the database, but left env1.jenv

This had the side effect of being able to juju switch to env1 (as the client goes off the .jenv files) but not being able to get the status for that environment (as it's been deleted from the State database). I was unable to create another environ named env1, even after destroying and bootstrapping the server environ - as the env1.jenv makes the client think we've already got an env1 environment.

Possible solution: When an environment is destroyed, all .jenvs connecting to that environment should be removed from .juju/environments.

Sorry, I misread this bug. OP is talking about the bootstrapped environment. I was testing the JES environment create feature - and found a bug non-the-less.

Okay, take two. Just tested this on 1.24-beta3.1 and the behaviour seems reasonable:

$ juju bootstrap
$ juju add user bob
$ juju destroy-environment bob
...
ERROR cannot destroy server environment without bootstrap infomation

The error clearly explains why the command fails (though I did just spot a typo) - bob.jenv doesn't have the bootstrap info. Also, bob.jenv is not removed.

I tried to recreate the problem using 1.23.2-utopic-amd64 and got the same results as Jesse did. This bug is five months old so it must have been fixed in subsequent versions. I wish I'd recorded the version I was using in the bug report.

If nothing else could you fix the typo "infomation"? :)

Thanks for looking at the bug.

We talked more about this and decided that the correct fix is to allow an environment to be destroyed from a user jenv. Here's the PR for that: http://reviews.vapour.ws/r/1794/