no way to remove k8s model when underlying k8s is removed

[Kevin W Monroe]

I often `juju add-k8s` atop a charmed kubernetes deployment. If i remove the charmed-k8s model before the k8s cloud model, there doesn't seem to be a way for me to remove the latter later.

Repro on juju 3.3.3 (from 3/stable):
------------------------------------
## deploy env

$ juju add-model ck8s
$ juju deploy charmed-kubernetes
... wait til it settles ...

$ kubeconfig="$(juju ssh kubernetes-control-plane/leader -- cat config)"
$ controller="$(juju controller-config controller-name)"
$ echo "$kubeconfig" | juju add-k8s k8s-cloud --controller "$controller" --skip-storage
$ juju add-model k8s-model k8s-cloud

## see k8s-cloud

$ juju clouds
Clouds available on the controller:
Cloud Regions Default Type
aws 27 af-south-1 ec2
k8s-cloud 1 default k8s

## destroy the ck8s model

$ juju destroy-model ck8s --force

## can't get rid of the k8s model

$ juju destroy-model k8s-model --force --debug
19:27:25 INFO juju.cmd supercommand.go:56 running juju [3.3.3 3e20d5947e407dcb4ce9c6fc29ba04b24978468e gc go1.20.14]
19:27:25 DEBUG juju.cmd supercommand.go:57 args: []string{"/snap/juju/26652/bin/juju", "destroy-model", "k8s-model", "--force", "--debug"}
19:27:25 INFO juju.juju api.go:86 connecting to API addresses: [52.33.159.255:17070 172.31.46.132:17070 252.46.132.1:17070]
19:27:25 DEBUG juju.api apiclient.go:1172 successfully dialed "wss://52.33.159.255:17070/api"
19:27:25 INFO juju.api apiclient.go:707 connection established to "wss://52.33.159.255:17070/api"
19:27:26 WARN cmd destroy.go:266 This command will destroy the "k8s-model" model and all its resources. It cannot be stopped.

To continue, enter the name of the model to be destroyed: k8s-model
Destroying model
Waiting for model to be removed.................................................
................................................................................
................................................................................
................................................................................
.....................

------------------------------------

This doesn't lead to catastrophic failure, but it's annoying that my controller thinks it knows about a model that it can not possibly ever interact with again. The default destroy-model should probably hang like it's doing today, but i would like --force to clean up the controller's view of the model whether it actually cleans anything up or just "unregisters" it.

On that note, a "juju unregister-model" would also work for me and would keep with the unregister paradigm we have for controllers.

[Joseph Phillips (manadart)]

Is there anything in the controller logs that illuminates?

[Ian Booth (wallyworld)]

This is the case where the underling cloud is gone forever. Just as we have juju unregister for controllers, we need something similar for models to simply remove the model from persistent state without attempting to interact with the cloud.