[openstack-dev] [cinder] Change reset-state to involve the driver

Mike Perez thingee at gmail.com
Fri Jan 23 20:00:49 UTC 2015


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



More information about the OpenStack-dev mailing list