Open Stack

A Cinder blueprint has been submitted to allow the python-cinderclient to involve the back end storage driver in resetting the state of a cinder volume:
https://blueprints.launchpad.net/cinder/+spec/reset-state-with-driver
and the spec:
https://review.openstack.org/#/c/134366

This blueprint contains various use cases for a volume that may be listed in the Cinder DataBase in state detaching|attaching|creating|deleting.
The Proposed solution involves augmenting the python-cinderclient command 'reset-state', but other options are listed, including those that
involve Nova, since the state of a volume in the Nova XML found in /etc/libvirt/qemu/<instance_id>.xml may also be out-of-sync with the
Cinder DB or storage back end.

A related proposal for adding a new non-admin API for changing volume status from 'attaching' to 'error' has also been proposed:
https://review.openstack.org/#/c/137503/

Some questions have arisen:
1) Should 'reset-state' command be changed at all, since it was originally just to modify the Cinder DB?
2) Should 'reset-state' be fixed to prevent the naïve admin from changing the CinderDB to be out-of-sync with the back end storage?
3) Should 'reset-state' be kept the same, but augmented with new options?
4) Should a new command be implemented, with possibly a new admin API to properly sync state?
5) Should Nova be involved? If so, should this be done as a separate body of work?

This has proven to be a complex issue and there seems to be a good bit of interest. Please provide feedback, comments, and suggestions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141128/eb74431a/attachment.html>