volume transfer request accept does not work

[Dean Troyer]

volume transfer request accept fails every time with CommandError: No volumetransfer with a name or ID of 'xfer-name' exists.

AcceptTransferRequest.take_action() uses utils.find_resource() to do a name/ID lookup to locate the transfer object, just like everything else in OpenStack. Only, by definition, the request is going to be in a different project. If the auth'ed user does not have _ADMIN_ permissions this lookup _WILL_ fail in the Cinder API call in cinderclient's VolumeTransferManager.find() when it tries to list all requests after the VolumeTransferManager.get() fails. Even by ID. Not sure why yet. Probably also permissions. After all, we can't have projects seeing other projects stuff, except that is the entire purpose of this command.

So, no name lookups for transfer request accept. Nice. Blind POST using only the ID.

Remove the utils.find() call from take_action(). Only ID is allowed here until the Cinder API is changed to also accept name directly.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/386770

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/386770
Committed: https://git.openstack.org/cgit/openstack/python-openstackclient/commit/?id=709eac73fbf0691d8012052773eec73006adf704
Submitter: Jenkins
Branch: master

commit 709eac73fbf0691d8012052773eec73006adf704
Author: Dean Troyer <email address hidden>
Date: Fri Oct 14 14:01:42 2016 -0500

    Fix volume transfers request commands

    * Fix volume transfer request accept to actually not crash when
      trying to call Volume API.
    * Fix volume transfer request accept syntax to have only one
      positional argument, which is the ID of the resource in the command
    * Change the output column order in volume transfer request list to
      have ID followed by Name then the remaining columns.

    Closes-bug: 1633582
    Change-Id: I5cc005f039d171cc70859f60e7fe649b09ead229

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/python-openstackclient 3.10.0 release.