Thanks to everyone who commented on the spec to change reset-state to involve the driver: https://review.openstack.org/#/c/134366/
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 opinion). 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 process. 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. scottda
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
