Public bug reported: Description ============
I did some test on boot from volume instance. I found that sometime the instance boot from volume will fail on evacuate operation. After some dig, I found evacuate operation failed due to the conductor service returned wrong block device mapping which has no connection info. After some more dig, I found there are some BDM should NOT exists because it belongs to a deleted instance. After some more test, I found a way to reproduce this problem. Steps to reproduce ==================== 1, create a volume from image (image-volume1) 2, stop or disable all nova-compute 3, boot an instance (bfv1) from volume (image-volume1) 4, wait the instance became ERROR state 5, delete the instance will just created 6, look at block_device_mapping table of nova database and found instance's block device mapping still exists 7, boot another instance (bfv2) from voluem (image-volume1) 8, execute evacuate operation on bfv2 9, evacuate operation failed and bfv2 became ERROR. Environment ============ * centos 7 * liberty openstack I looked at the master branch code. This bug still exists. ** Affects: nova Importance: Undecided Status: New -- 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/1583999 Title: BDM is not deleted if an instance booted from volume and failed on schedule stage Status in OpenStack Compute (nova): New Bug description: Description ============ I did some test on boot from volume instance. I found that sometime the instance boot from volume will fail on evacuate operation. After some dig, I found evacuate operation failed due to the conductor service returned wrong block device mapping which has no connection info. After some more dig, I found there are some BDM should NOT exists because it belongs to a deleted instance. After some more test, I found a way to reproduce this problem. Steps to reproduce ==================== 1, create a volume from image (image-volume1) 2, stop or disable all nova-compute 3, boot an instance (bfv1) from volume (image-volume1) 4, wait the instance became ERROR state 5, delete the instance will just created 6, look at block_device_mapping table of nova database and found instance's block device mapping still exists 7, boot another instance (bfv2) from voluem (image-volume1) 8, execute evacuate operation on bfv2 9, evacuate operation failed and bfv2 became ERROR. Environment ============ * centos 7 * liberty openstack I looked at the master branch code. This bug still exists. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1583999/+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