Comment 0 for bug 1876104

Revision history for this message
Gareth Woolridge (moon127) wrote :

Attempting to destroy-model --force on a k8s model with persistent storage spins forever:

juju destroy-model discourse --force
WARNING! This command will destroy the "discourse" model.
This includes all containers, applications, data and other resources.

Continue [y/N]? y
Destroying model
Waiting for model to be removed, 1 application(s), 1 volume(s), 1 filesystems(s)..........................................................................................................................................................^Cctrl+c detected, aborting...

However checking juju debug-log -m controller:

controller-0: 14:33:24 WARNING juju.apiserver.common failed destroying model 5c03e992-ce74-48a9-89f0-1cbce2ee550b: failed to destroy model: model contains persistent storage

So list storages, and try to delete manually:

juju list-storage
Unit Storage id Type Pool Size Status Message
discourse-charm/0 discourse-storage/0 filesystem kubernetes 48MiB attached Successfully provisioned volume pvc-60ba8b8b-b388-427d-833a-80b7b0374e47

juju remove-storage discourse-storage/0
ERROR Juju command "remove-storage" not supported on kubernetes models

At this point I asked in #juju and hml suggested --destroy-storage:

 "discourse" model.
This includes all containers, applications, data and other resources.

Continue [y/N]? y
Destroying model
Waiting for model to be removed, 1 application(s), 1 volume(s), 1 filesystems(s).....
Waiting for model to be removed, 1 application(s).......................
Waiting for model to be removed......
Model destroyed.

So this works. I can't quite recall why I was using --force, likely as iterating on a new operator charm and needing to kick broken units/models harder on destroy before I added storage to the charm.

Anyway, this feel bug worthy on feedback from --force from an end user perspective if using with k8s and storage, as it spins forever with no feedback of an issue unless you know to look in the controller logs.