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

[Brad Crittenden]

An environment was created and then 'juju user add' was used to add a user and create a new .jenv file with the new user's credentials, call it user.jenv.

After installing user.jenv into $JUJU_HOME/environments, using 'juju destroy-environment user' resulted in
the message "removing empty environment file" but does not destroy the environment.

If secondary users are not allowed to destroy the environment that should be documented. The message printed should be more explicit and should not delete the user.jenv file if the environment is not destroyed.

[Curtis Hovey (sinzui)]

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.

[Tim Penhey (thumper)]

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.

[Tim Penhey (thumper)]

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

[Jesse Meek (waigani)]

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.

[Jesse Meek (waigani)]

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.

[Jesse Meek (waigani)]

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.

[Brad Crittenden (bac)]

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.

[Jesse Meek (waigani)]

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/