cinder force-delete of an attached volume fails and puts system into a inconsistent state

[Michael Kerrin]

If you run "cinder force-delete" on a a volume that is attached it will run saying nothing, thinking it ran successfully.

In the background the cinder-api accepted the request to force delete the volume and passes this request it on to the cinder-volume service which does not accept deleting volumes in this state. Thus the volume will not be deleted, but the volume has been put in the deleting state.

The volume is now in the deleting state and cinder-volume will refuse to delete it.

This is counter to what cinderclient force-delete command says it does, delete volumes, regardless of it's state.

If the cinder-volume service is restarted it will see the volume in the deleting state and try to delete it. This will fail as the volume is still attached and the cinder-volume will go into an infinite loop trying to delete a volume it can't

[John Griffith (john-griffith)]

The cinder force-delete help states it will "Attempt forced removal of a volume, regardless of it's state." Key here being the word "Attempt".

Maybe this isn't overly clear and could be improved. Bailing out on the delete if it's attached is not such a bad thing, but we should consider responding sooner in the stack with a helpful message and NOT locking you out with the "deleting" state.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/31165

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/31165
Committed: http://github.com/openstack/cinder/commit/8829bb1a1d726bd6b1b6b623c0ac498d1ec05d41
Submitter: Jenkins
Branch: master

commit 8829bb1a1d726bd6b1b6b623c0ac498d1ec05d41
Author: Mike Perez <email address hidden>
Date: Fri May 31 00:11:24 2013 -0700

    Prevent force delete if the volume is attached

    Force deletes were eventually failing on the volume manager layer due to
    being in an attached state. This will check that up front to inform the
    user that they need to detach first.

    Fixes: bug #1164929
    Change-Id: I24ade24fd750dc647331ef25b835f45f29c10fd7