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
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
