<div dir="ltr"><div><div><div><div><div><div><div><div><div>John:<br><br></div>States that the driver can/should do some cleanup work during the transition:<br><br></div>attaching -> available or error<br></div>detaching -> available or error<br></div>error -> available or error<br></div>deleting -> deleted or error_deleting<br><br></div><div>Also in possibly wanted in future but much harder:<br></div>backing_up -> available or error (need to make sure the backup service copes)<br></div>restoring -> error (need to make sure the backup service copes)<br></div><br></div>I haven't looked at the entire state space yet, these are the obvious ones off the top of my head<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 December 2014 at 06:30, John Griffith <span dir="ltr"><<a href="mailto:john.griffith8@gmail.com" target="_blank">john.griffith8@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Nov 28, 2014 at 11:25 AM, D'Angelo, Scott <<a href="mailto:scott.dangelo@hp.com">scott.dangelo@hp.com</a>> wrote:<br>
> A Cinder blueprint has been submitted to allow the python-cinderclient to<br>
> involve the back end storage driver in resetting the state of a cinder<br>
> volume:<br>
><br>
> <a href="https://blueprints.launchpad.net/cinder/+spec/reset-state-with-driver" target="_blank">https://blueprints.launchpad.net/cinder/+spec/reset-state-with-driver</a><br>
><br>
> and the spec:<br>
><br>
> <a href="https://review.openstack.org/#/c/134366" target="_blank">https://review.openstack.org/#/c/134366</a><br>
><br>
><br>
><br>
> This blueprint contains various use cases for a volume that may be listed in<br>
> the Cinder DataBase in state detaching|attaching|creating|deleting.<br>
><br>
> The Proposed solution involves augmenting the python-cinderclient command<br>
> ‘reset-state’, but other options are listed, including those that<br>
><br>
> involve Nova, since the state of a volume in the Nova XML found in<br>
> /etc/libvirt/qemu/<instance_id>.xml may also be out-of-sync with the<br>
><br>
> Cinder DB or storage back end.<br>
><br>
><br>
><br>
> A related proposal for adding a new non-admin API for changing volume status<br>
> from ‘attaching’ to ‘error’ has also been proposed:<br>
><br>
> <a href="https://review.openstack.org/#/c/137503/" target="_blank">https://review.openstack.org/#/c/137503/</a><br>
><br>
><br>
><br>
> Some questions have arisen:<br>
><br>
> 1) Should ‘reset-state’ command be changed at all, since it was originally<br>
> just to modify the Cinder DB?<br>
><br>
> 2) Should ‘reset-state’ be fixed to prevent the naïve admin from changing<br>
> the CinderDB to be out-of-sync with the back end storage?<br>
><br>
> 3) Should ‘reset-state’ be kept the same, but augmented with new options?<br>
><br>
> 4) Should a new command be implemented, with possibly a new admin API to<br>
> properly sync state?<br>
><br>
> 5) Should Nova be involved? If so, should this be done as a separate body of<br>
> work?<br>
><br>
><br>
><br>
> This has proven to be a complex issue and there seems to be a good bit of<br>
> interest. Please provide feedback, comments, and suggestions.<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
Hey Scott,<br>
<br>
Thanks for posting this to the ML, I stated my opinion on the spec,<br>
but for completeness:<br>
My feeling is that reset-state has morphed into something entirely<br>
different than originally intended.  That's actually great, nothing<br>
wrong there at all.  I strongly disagree with the statements that<br>
"setting the status in the DB only is almost always the wrong thing to<br>
do".  The whole point was to allow the state to be changed in the DB<br>
so the item could in most cases be deleted.  There was never an intent<br>
(that I'm aware of) to make this some sort of uber resync and heal API<br>
call.<br>
<br>
All of that history aside, I think it would be great to add some<br>
driver interaction here.  I am however very unclear on what that would<br>
actually include.  For example, would you let a Volume's state be<br>
changed from "Error-Attaching" to "In-Use" and just run through the<br>
process of retyring an attach?  To me that seems like a bad idea.  I'm<br>
much happier with the current state of changing the state form "Error"<br>
to "Available" (and NOTHING else) so that an operation can be retried,<br>
or the resource can be deleted.  If you start allowing any state<br>
transition (which sadly we've started to do) you're almost never going<br>
to get things correct.  This also covers almost every situation even<br>
though it means you have to explicitly retry operations or steps (I<br>
don't think that's a bad thing) and make the code significantly more<br>
robust IMO (we have some issues lately with things being robust).<br>
<br>
My proposal would be to go back to limiting the things you can do with<br>
reset-state (basicly make it so you can only release the resource back<br>
to available) and add the driver interaction to clean up any mess if<br>
possible.  This could be a simple driver call added like<br>
"make_volume_available" whereby the driver just ensures that there are<br>
no attachments and.... well; honestly nothing else comes to mind as<br>
being something the driver cares about here. The final option then<br>
being to add some more power to force-delete.<br>
<br>
Is there anything other than attach that matters from a driver?  If<br>
people are talking error-recovery that to me is a whole different<br>
topic and frankly I think we need to spend more time preventing errors<br>
as opposed to trying to recover from them via new API calls.<br>
<br>
Curious to see if any other folks have input here?<br>
<br>
John<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Duncan Thomas</div>
</div>