As discussed on several proposed patches around this (see https://review.openstack.org/#/c/80619/ or https://review.openstack.org/#/c/80619/ which actually rejects this solution).
I will move this bug to "won't fix", and will raise a BP targeted for Juno to use some of the code added in https://blueprints.launchpad.net/nova/+spec/admin-event-callback-api to make interactions between nova and cinder better and avoid the need for a configurable timeout. ** Changed in: nova Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1280357 Title: parameters max_tries and wait_between of method ComputeManager._await_block_device_map_created should be configurable Status in OpenStack Compute (Nova): Won't Fix Bug description: When using a weak storage backend and initiating the creation of a lot of new instances using volumes as backend (directly created from an image) I got a lot of InvalidBDM: Block Device Mapping is Invalid. After I had a look on the method _await_block_device_map_created (in nova/manager/ComputeManager) the solution was pretty easy: increasing the max_tries and/or wait_between parameters solved the issue. The storage backend could simply not provide this mass of volumes in a very short time (100 seconds on my testing system). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1280357/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
