providing different imageRef when using block_device_mapping (image -> volume)

[Mohamed Osman]

When booting instance with block_device_mapping_v2 provided with source_type set to "image" and also providing imageRef with a different uuid than the one provided in block_device_mapping_v2.uuid the instance will be booted but it will contain image metadata from the imageRef while the boot volume with have image meta data from the block_device_mapping_v2.uuid field.

Steps to reproduce
==================

Step 1:
=======
call /servers api curl REQ:

curl -g -i -X POST http://nova-endpoint:8774/v2/5ee09552880049c6b56f96c99081ddf1/servers -H "Content-Type: application/json; charset=UTF-8" -H "X-Auth-Token: authtoken" -H "Content-Type: application/json" -d '{"server": {"name": "new-server-test","imageRef": "cbb2746c-6342-4946-84ab-09ca0c8be82b","flavorRef": "2e7f5353-cff7-4723-bbec-b35b12999d83","availability_zone": "zone-1","block_device_mapping_v2": [{"boot_index": "0","uuid": "1616a9c4-a6f4-4bed-99dc-a742695d9999","source_type": "image","volume_size": "30","destination_type": "volume","delete_on_termination": false}]}}'

Step 2:
=======
check server information: openstack server show 5e903f37-318e-4b03-a9ad-1cea598fa313 -c name -c image -c os-extended-volumes:volumes_attach

+--------------------------------------+-----------------------------------------------------------+
| Field | Value |
+--------------------------------------+-----------------------------------------------------------+
| image | Image1 (cbb2746c-6342-4946-84ab-09ca0c8be82b) |
| name | new-server-test |
| os-extended-volumes:volumes_attached | [{u'id': u'e03eb79c-67d8-4c4c-997e-fe3eeb400968'}] |
+--------------------------------------+-----------------------------------------------------------+

Step 3:
=======
check volume information: openstack volume show e03eb79c-67d8-4c4c-997e-fe3eeb400968 -c volume_image_metadata

+-----------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| volume_image_metadata | {u'description': u'', u'checksum': u'e7f6e7d7d38423a705394ad72fdb823c', u'min_ram': u'0', u'disk_format': u'qcow2', u'image_name': u'Image2', u'image_id': |
| | u'1616a9c4-a6f4-4bed-99dc-a742695d9999', u'container_format': u'bare', u'min_disk': u'30', u'size': u'8823242752'} |
+-----------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Expected Result
===============
server should not be tagged with image image1 since the actual image source is the image2 specified in block_device_mapping_v2.

Actual Result
==============
server is tagged with image image1

[Mohamed Osman (meothman)]

Should Nova API validate that when specifying both imageRef and block_device_mapping_v2 with source image that both images be the same?

[Roman Podoliaka (rpodolyaka)]

Mohamed, could you please clarify which version of Nova are you using? I tried this on my master (Ocata) devstack and see the proper (in my opinion) error:

{"badRequest": {"message": "Block Device Mapping is Invalid: Boot sequence for the instance and image/block device mapping combination is not valid.", "code": 400}}

as you can't specify both `imageRef` and `boot_index=0` at the same time.

[Roman Podoliaka (rpodolyaka)]

Oops, sorry, comment #1 was based on my experience of using python-novaclient CLI. I can reproduce the problem by issuing an API request manually and specifying both block device mapping (to boot from a volume created from an image) and imageRef at the same time.

[Roman Podoliaka (rpodolyaka)]

Anyway, this should be a minor issue with reporting: instance is booted properly from a volume, as expected, it's just it does not say "Attempt to boot from volume - no image supplied" in "image" column in `nova show` output, but shows an image id instead.

[Mohamed Osman (meothman)]

Is there a possible valid scenario for using both imageRef and block_device_mapping_v2 together? I have tested with using boot from volume (block_device_mapping source:volume) and the image metadata is still added to the server. Should the behavior of the API be that imageRef and block_device_mapping_v2 are mutually exclusive? and if so should the behavior be to ignore the value provided in imageRef or to return a 400 bad request as the CLI client?

[Sean Dague (sdague)]

There are no currently open reviews on this bug, changing the status back to the previous state and unassigning. If there are active reviews related to this bug, please include links in comments.