Comment 5 for bug 1818045

I cannot reproduce this at all.

I have tried different versions of Juju - 2.4.8, 2.5.3, 2.6-wip.
I have tried different kafka charms - both from the charmstore (without storage) and ~cmars one with storage, including with combination of subordinates and peers like filebeat and telegraf.

Your version of kafka failed to install and, in fact, all hooks failed. I have used 'resolved' to get passed the hooks to get to 'stable' model.

What I did see was that there was a bit of flakiness around storage. For example, when attaching storage before the machine has reported as started, storage was stuck in permanently 'pending' status. I think that there is a bug for that. However, all machines, application and models were removed/destroyed successfully.

I have spent most of the time in 2.4 since this is the version that was causing issue for you. However, whilst I did manage to get a similar error logged as you (see your extract in comment # 4), the machine consistently went away without a problem for me.

In the versions after 2.4, we did improve how we deal with /dev device mapping. It could be accounting for the fact that I saw less flakiness in later versions.

At this point, without a reproducible scenario to help address the root cause, I prefer to focus on providing you and other users with 'remove-application' and 'remove-unit' --force. It is not ideal since it does not fix what got you in that state. However, at least, it will give you a way forward.

As part of this work, I am also ensuring that 'remove-machine --force' will ignore and will succeed despite storage errors, directly addressing your attempts at clean up.