yahoo-eng-team team mailing list archive

[Jiajun Liu <iamljj@xxxxxxxxx>]

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