yahoo-eng-team team mailing list archive

[Alexander Diana <1881944@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: nova
     Importance: Undecided
         Status: New

** Description changed:

  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.

-- 
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):
  New

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