Lxd: Can't delete absent storage if volumes were attached to it

[rmader]

This is probably related to (and partly fixed by) #3775

When trying to delete an absent storage pool (that is: it's not mounted or the file structure got deleted by other means) that had volumes attached to it (containers, images), it obviously fails with

# lxc storage delete dev
error: storage pool "dev" has volumes attached to it

So first I'd have to delete the volumes, but this in turn fails with the error:

# lxc storage volume delete dev 58f90cbf68927c3fc43e6ee1386446a04f3d8068c1a75a291339cb2be01dec08
error: not found

I think it would be nice to have a similar check like in the patches for #3775

Ubuntu 16.04, LXD 2.17

[brauner]

Right, this situation should be solvable with my branch which landed in git master. You should be able to remove the remaining non-existing storage volumes from the storage pool and then finally remove the non-existing storage pool itself.

I don't much like the idea of deleting the pool when it has volumes attached to it even if the pool doesn't seem to exist anymore. The problem with this approach also is that the checks whether the pools is used is not happening in the driver implementations themselves but rather when the API request hits the daemon. I very much like to keep it this way if we move it into the drivers themselves we will take a performance hit since we need to initialize a new storage interface.

[brauner]

That being said, btrfs might be a little special as the pool needs to be mounted before the delete can proceed. I'm off today but I'm sure I can come up with something tomorrow.

[stgraber]

Pretty sure this indeed did get fixed yesterday. The other issue in the initial report here is that to delete an image you need to prefix it with image/.

So you'd have wanted:

lxc storage volume delete dev image/58f90cbf68927c3fc43e6ee1386446a04f3d8068c1a75a291339cb2be01dec08

[rmader]

Ah alright, thanks!

[zQueal]

I'm very new to LXC/LXD--but this entire process seems very unconventional to me.

After creating a pool (default)--and a subsequent container attached to it--removing the images and storage pool created was incredibly difficult and arbitrary. Even after I was able to remove the images (which totaled 1GB on my SSD) I was unable to remove the default storage pool because there was a profile associated with it.

There seems to be a desperate need for a garbage collection feature which can find orphaned images, profiles, and containers to remove them.