unmanage operation overloads "deleting" state

[Eric Harney]

The following sequence of events doesn't look safe:

1. Issue a "cinder unmanage" command, which puts a volume in "deleting" state as it begins the unmanage process.
2. Cinder volume restarts due to failure
3. Upon resume, Cinder volume manager will detect the "deleting" state and now issue a delete volume request w/o the unmanage flag, which is more destructive than the admin intended and may cause accidental data loss.

[Sean McGinnis (sean-mcginnis)]

Unassigning due to no activity.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/405620
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=3b17143979ef22f235e868301ee84866860061bf
Submitter: Jenkins
Branch: master

commit 3b17143979ef22f235e868301ee84866860061bf
Author: Eric Harney <email address hidden>
Date: Fri Oct 28 09:38:21 2016 +0200

    Add 'unmanaging' state to volumes and snapshots

    'unmanaging' is different from 'deleting', and must
    be distinguishable to know how to recover from a failed
    delete/unmanage operation. The current state of things
    makes it so that an 'unmanaging' volume may end up being
    accidentally deleted.

    Add unmanage notifications, as well.

    Partial-Bug: #1478959

    Change-Id: I06f60a584f219043673095346282c429773704f8

[Eric Harney (eharney)]

3b17143979 was tagged "Partial-Bug", but should have been "Closes-Bug".