Destroyed models still show up in list-models

[Cheryl Jennings]

After destroying a model, it still shows up in list-models. It should either be removed, or indicate that it is dead.

$ juju list-models
NAME OWNER LAST CONNECTION
amazon admin@local just now
amazon2 admin@local 8 seconds ago

$ juju destroy-model amazon2
WARNING! This command will destroy the "amazon2" environment.
This includes all machines, services, data and other resources.

Continue [y/N]? y

$ juju list-models
NAME OWNER LAST CONNECTION
amazon admin@local just now
amazon2 admin@local 37 seconds ago

$ juju switch amazon2
ERROR "amazon2" is not a name of an existing defined environment or controller

[Andreas Hasenack (ahasenack)]

Just to add to this byg, with 2.0a2 I have a similar but slightly different behavior: list-models complains that the destroyed model no longer exists:

andreas@duo:~$ juju destroy-model andreas21
WARNING! This command will destroy the "andreas21" model.
This includes all machines, services, data and other resources.

Continue [y/N]? y

andreas@duo:~$ juju list-models
ERROR model "andreas21" not found

"andreas21" was the only model besides the first one created during bootstrap, which still exists:
andreas@duo:~$ juju status -m lxd
[Services]
NAME STATUS EXPOSED CHARM

[Units]
ID WORKLOAD-STATE AGENT-STATE VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE

[Machines]
ID STATE DNS INS-ID SERIES AZ
0 started 10.0.3.131 juju-e54588dd-0ecc-4630-86ec-ebac0c79c13d-machine-0 trusty

[Cheryl Jennings (cherylj)]

@ahasenack - That is a slightly different bug, see bug #1545589

[Peter Matulis (petermatulis)]

I hit this today. I noticed, however, that I can indeed switch to the "destroyed" model.

$ dpkg-query -W juju-core2
juju-core2 2.0-beta1-0ubuntu1~16.04.1~juju1

[Andrew Wilkins (axwalk)]

Dead models are kept around in the DB for post-mortems. There's a couple of issues with this:
 - dead models still show up in list-models
 - you can "juju switch" to dead models
 - dead models can be referenced by commands (e.g. "juju destroy-model" will happily destroy a previously destroyed model, provided you switch to them first)
 - the names of dead models cannot be reused until the model is eventually reaped from the DB

I think we should look at renaming models when they're set to "dead", such that the name can be reused; and we should not allow dead models to leak into the UI, except perhaps when explicitly requested.

[Adam Stokes (adam-stokes)]

I discussed this a bit with Cheryl but to recap:

If a model is destroyed but still listed as available our application will think it is a acceptable model to deploy to:

https://usercontent.irccloud-cdn.com/file/ZhkFkpHo/

All but 'moo7' have been destroyed.

[Richard Harding (rharding)]

We should

1) not show destroyed models by default, add a flag for --archived which will show the list of archived models with their new names.

2) rename the models on destroy to being $modelname-archive so the names can be reused again.

We should try if at all possible to do this for the 2.0 final release since it'll be a backward compatible change issue.

[Andrew Wilkins (axwalk)]

> 1) not show destroyed models by default, add a flag for --archived which will show the list of archived models with their new names.

Lifecycle is not boolean though, it's ternary. A model (most entities in Juju for that matter) can be Alive, Dying, or Dead. Until all of the resources in a model are destroyed, the model will be in the Dying state. IMO, the model should always show up in the list while Alive or Dying, but not Dead (unless --archived). I think it also makes sense to add "status" entries for models: i.e. something like "available", "migrating", "importing", "destroying".

I propose the following:
 1) add "life", and "juju-status" to the YAML and JSON output of list-models
 2) add a new "STATE" (STATUS? We're not consistent in existing output) column to the tabular output.
 3) filter out life=Dead models unless --archived

Adam's application should use the YAML or JSON output, and filter out all models except those with life=Alive.

> 2) rename the models on destroy to being $modelname-archive so the names can be reused again.

Agree in principle, but I'm looking for a naming scheme that a user is not permitted to specify. For example, a user *could* create a model called "icantbelieveitsnot-archived"; but they cannot create "icantbelieveitsnot/archived". So the latter may be safer.

[Richard Harding (rharding)]

I think that if the user calls it 'icantblieveitsnot-archived and we rename it then you end up with -archived-archived. It's consistent, the status output shows that it's archived or dead or what not. I guess i'm not worried about the doubling up name if folks use that. Doing things with / and such mean we end up where paths/urls could be issues.

[Andrew Wilkins (axwalk)]

For others' benefit: Rick, thumper, wallyworld and I had a chat about this on IRC, and came to the conclusion that keeping dead models around in state is causing more problems than it's solving, and so we'll get rid of the "keep around for 24h" aspect.

I have amended my changes so that:
 1) There is no more "archived" status. A model will start out as "available", and will go to "destroying". From there, it will be removed from state. altogether
 2) Because of the above, it no longer makes sense to have an --archived flag, so it has been removed.

You'll still be able to see the "life" field in the JSON/YAML output, and should base scripting around that, rather than the status.