yahoo-eng-team team mailing list archive

[Elod Illes <1881944@xxxxxxxxxxxxxxxxxx>]

** Changed in: nova/ussuri
       Status: Fix Committed => Fix Released

** Changed in: nova/victoria
       Status: Fix Committed => Fix Released

-- 
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/1881944

Title:
  nova-api returns empty block-device-mapping in metadata queries

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) train series:
  In Progress
Status in OpenStack Compute (nova) ussuri series:
  Fix Released
Status in OpenStack Compute (nova) victoria series:
  Fix Released

Bug description:
  Description
  ===========
  currently in a single cell deployment with nova-api acting as metadata server, queries for block-device-mapping end up going to the nova_cell0/block_device_mapping table instead of nova${the_actual_cell}/block_device_mapping, resulting in empty results other than the dynamically generated root/ami entries.

  This results in an empty response, even though the devices are mapped
  and present in the appropriate table.

  Steps to reproduce
  ==================
  1. Use nova train or greater (tested on stable/train current HEAD)
  2. curl 169.254.169.254/latest/meta-data/block-device-mapping/ from an instance with volumes attached
  3. receive only root and ami, no entries for volumes

  Expected result
  ===============
  There should be entries in block-device-mapping queries for each volume mapped to the instance.

  Actual result
  =============
  There are no entries other than root/ami in the block-device-mapping

  Notes
  ===========
  This is "fixed" by pointing nova-api at the nova database instead of nova_cell0

  This bug affects Train+, but likely any deployment with multiple
  cells.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1881944/+subscriptions