Thanks to everyone who commented on the spec to change reset-state to involve 
the driver:

I've put some comments in reply, and I'm going to attempt to capture the 
various ideas here. I hope we can discuss this at the Mid-Cycle in Austin.
1) The existing reset-state python-cinderclient command should not change in 
unexpected ways and shouldn't have any new parameters (general consensus here). 
It should not fail if the driver does not implement my proposed changes (my 
2) The existing reset-state is broken for some use cases (my UseCase2, for 
example, when stuck in 'attaching' but volume is still attached to instance). 
Existing reset-state will work for other situations (my UseCase1, when stuck in 
'attaching' but not really attached.
3)MikeP pointed out that moving _reset_status() would break clients. I could 
use help with understanding some of the API code here.
4) Xing had noted that this doesn't fix Nova. I hope we can do that separately, 
since this is proving contentious enough. Some cases such as a timeout during 
initialize_connection() could be fixed in Nova with a bug once this change is 
in. Other Nova changes might require a new Nova API to call for cleanup during 
reset-state, and that sounds much more difficult to get through the Nova change 
5) Walt suggested a new driver method reset_state(). This seems fine, although 
I had hoped terminate_connection() and detach_volume() would cover all possible 
cleanup in the driver.
6) MikeP pointed out that difficulty of getting 30+ drivers to implement a 
change. I hope that this can be done in such a way that the reset-state 
commands works exactly as it does today if this is not implemented in the 
driver. Putting code in the driver to improve what exists today would be 
strictly optional.

Thanks again. See you in Austin.

OpenStack Development Mailing List (not for usage questions)

Reply via email to