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.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
