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