John: States that the driver can/should do some cleanup work during the transition:
attaching -> available or error detaching -> available or error error -> available or error deleting -> deleted or error_deleting Also in possibly wanted in future but much harder: backing_up -> available or error (need to make sure the backup service copes) restoring -> error (need to make sure the backup service copes) I haven't looked at the entire state space yet, these are the obvious ones off the top of my head On 1 December 2014 at 06:30, John Griffith <[email protected]> wrote: > On Fri, Nov 28, 2014 at 11:25 AM, D'Angelo, Scott <[email protected]> > wrote: > > 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 > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > Hey Scott, > > Thanks for posting this to the ML, I stated my opinion on the spec, > but for completeness: > My feeling is that reset-state has morphed into something entirely > different than originally intended. That's actually great, nothing > wrong there at all. I strongly disagree with the statements that > "setting the status in the DB only is almost always the wrong thing to > do". The whole point was to allow the state to be changed in the DB > so the item could in most cases be deleted. There was never an intent > (that I'm aware of) to make this some sort of uber resync and heal API > call. > > All of that history aside, I think it would be great to add some > driver interaction here. I am however very unclear on what that would > actually include. For example, would you let a Volume's state be > changed from "Error-Attaching" to "In-Use" and just run through the > process of retyring an attach? To me that seems like a bad idea. I'm > much happier with the current state of changing the state form "Error" > to "Available" (and NOTHING else) so that an operation can be retried, > or the resource can be deleted. If you start allowing any state > transition (which sadly we've started to do) you're almost never going > to get things correct. This also covers almost every situation even > though it means you have to explicitly retry operations or steps (I > don't think that's a bad thing) and make the code significantly more > robust IMO (we have some issues lately with things being robust). > > My proposal would be to go back to limiting the things you can do with > reset-state (basicly make it so you can only release the resource back > to available) and add the driver interaction to clean up any mess if > possible. This could be a simple driver call added like > "make_volume_available" whereby the driver just ensures that there are > no attachments and.... well; honestly nothing else comes to mind as > being something the driver cares about here. The final option then > being to add some more power to force-delete. > > Is there anything other than attach that matters from a driver? If > people are talking error-recovery that to me is a whole different > topic and frankly I think we need to spend more time preventing errors > as opposed to trying to recover from them via new API calls. > > Curious to see if any other folks have input here? > > John > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Duncan Thomas
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
