yahoo-eng-team team mailing list archive

[OpenStack Infra <1881944@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/752459
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=1390eecf8dec4c3b022a9b1e259a908197566738
Submitter: Zuul
Branch:    master

commit 1390eecf8dec4c3b022a9b1e259a908197566738
Author: Balazs Gibizer <balazs.gibizer@xxxxxxxx>
Date:   Mon Sep 21 17:21:18 2020 +0200

    Use cell targeted context to query BDMs for metadata
    
    The metadata service supports a multicell deployment in a configuration
    where the nova-api service implements the metadata API. In this case the
    metadata query needs to be cell targeted. This was partly implemented
    already. The instance itself is queried from the cell DB properly.
    However the BDM data used the non targeted context resulting in an empty
    BDM returned by the metadata service.
    
    Functional reproduction test is not added as I did not find a way to
    have a cell setup in the functional test that reproduce the problem. I
    reproduced the bug and tested the fix in a devstack.
    
    Change-Id: I48f57082edaef3ec4722bd31ce29a90b94d32523
    Closes-Bug: #1881944


** Changed in: nova
       Status: In Progress => 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

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