On 19:44 Thu 22 Jan , D'Angelo, Scott wrote:
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.
Scott thanks for your work on this! I think your last comments have clarified
things for me and I really like the direction this is going. I have replied to
the review with some addition comments to add your ideas as I would like to
keep the discussion in the review. Thanks!
--
Mike Perez
__
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
