Comment 6 for bug 1897424

Revision history for this message
Jorhson Deng (jorhson) wrote :

Maybe i have not described clearly in c#4.
The application scenarios is to attach more than one volume and the timeout is not taken placed in reserve_block_device_name, but happened in attach_volume fucntion of n-cpu. Because if the first the volume attaching process take too long time in attach_volume fucntion, and if i attach the second volume at the same time, the n-api will post the PRC call to n-cpu, however, the n-cpu will not deal the second volume's request, because it's still dealing with the first volume attaching. So, if the first volume attaching takes too long time, which will lead to timeout in second volume attaching of _create_volume_bdm fucntion in n-api. And the n-cpu don't know the n-api has time out, and it will deal with the RPC call requet after the first volume attached completely.
And there no logs in reserve_block_device_name about the second volume in n-cpu, it just deal the RPC call request and return BDM object. the timeout isn't taken place in reserve_block_device_name, but in attach_volume in manager.py function for attaching the first volume.
If the instance has a task state to indecate the volume attaching process, it call be forbidden to attach another volume when the current volume attaching process not completed.