Public bug reported: If an image has settings for the same device in both 'mappings' and 'block_device_mapping' properties, the last one should be used for instance launch. But currently 'mappings' takes precedence.
============= Steps to reproduce: 1 Create a flavor with ephemeral disk. openstack flavor create m1.nano-ephemeral --id 142 --ram 64 --ephemeral 1 2 Set mapping property in an image: openstack image set --property mappings='[{"device": "vdb", "virtual": "ephemeral0"}]' cirros-0.3.4-x86_64-uec 3 Check expected mappings: euca-describe-images IMAGE ami-00000001 ... BLOCKDEVICEMAPPING /dev/vdb 3 Create a volume: openstack volume create empty --size 1 4 Create a snapshot: openstack snapshot create empty --name empty | Field | Value | | id | af84c37e-3521-435f-9976-e45aaf7fa2c7 | 5 Set bdm property in the image with the snapshot id and the same device name: openstack image set --property block_device_mapping='[{"device_name": "/dev/vdb", "boot_index": -1, "source_type": "snapshot", "destination_type": "volume", "volume_size": 1, "delete_on_termination": true, "snapshot_id": "af84c37e-3521-435f-9976-e45aaf7fa2c7"}]' --property bdm_v2=true cirros-0.3.4-x86_64-uec 6 Check expected mappings: euca-describe-images IMAGE ami-00000001 ... BLOCKDEVICEMAPPING /dev/vdb snap-00000001 1 true Here we see that bdm overloads mappings. 7 Boot an instance with the image: nova boot --flavor m1.nano-ephemeral --image cirros-0.3.4-x86_64-uec inst 8 Wait active state of the instance and view its volumes: nova show inst | Property | Value | | os-extended-volumes:volumes_attached | [] | ============= Actual result: no volume is attached to the instance. Expected result: an id of an attached volume. ============= Since Nova EC2 has not been changed for a long time, it still processes these properties in right order. So these steps use EC2 API to display expected results. Also see _setUpImageSet in test_cloud.py. Pay attention to mapping1, block_device_mapping1, _expected_bdms1 vars. Tests ensures that bdm overloads mappings for showing images. The behavior is broken by https://review.openstack.org/#/c/83805 See there in L636 of api.py: if image_mapping: image_defined_bdms += self._prepare_image_mapping( instance_type, image_mapping) Compare with left side's L1163: for mapping in (image_mapping, block_device_mapping): if not mapping: continue self._update_block_device_mapping(context, instance_type, instance_uuid, mapping) I think it's safe to restore the old behavior. ** Affects: nova Importance: Undecided Status: New ** Description changed: If an image has settings for the same device in both 'mappings' and 'block_device_mapping' properties, the last one should be used for instance launch. But currently 'mappings' takes precedence. ============= Steps to reproduce: 1 Create a flavor with ephemeral disk. openstack flavor create m1.nano-ephemeral --id 142 --ram 64 --ephemeral 1 2 Set mapping property in an image: openstack image set --property mappings='[{"device": "vdb", "virtual": "ephemeral0"}]' cirros-0.3.4-x86_64-uec 3 Check expected mappings: euca-describe-images IMAGE ami-00000001 ... BLOCKDEVICEMAPPING /dev/vdb 3 Create a volume: openstack volume create empty --size 1 4 Create a snapshot: openstack snapshot create empty --name empty - +---------------------+--------------------------------------+ | Field | Value | - +---------------------+--------------------------------------+ | id | af84c37e-3521-435f-9976-e45aaf7fa2c7 | 5 Set bdm property in the image with the snapshot id and the same device name: openstack image set --property block_device_mapping='[{"device_name": "/dev/vdb", "boot_index": -1, "source_type": "snapshot", "destination_type": "volume", "volume_size": 1, "delete_on_termination": true, "snapshot_id": "af84c37e-3521-435f-9976-e45aaf7fa2c7"}]' --property bdm_v2=true cirros-0.3.4-x86_64-uec 6 Check expected mappings: euca-describe-images IMAGE ami-00000001 ... BLOCKDEVICEMAPPING /dev/vdb snap-00000001 1 true Here we see that bdm overloads mappings. 7 Boot an instance with the image: nova boot --flavor m1.nano --image cirros-0.3.4-x86_64-uec inst 8 Wait active state of the instance and view its volumes: nova show inst - +--------------------------------------+----------------------------------------------------------------+ | Property | Value | - +--------------------------------------+----------------------------------------------------------------+ | os-extended-volumes:volumes_attached | [] | ============= Actual result: no volume is attached to the instance. Expected result: an id of an attached volume. ============= Since Nova EC2 has not been changed for a long time, it still processes these properties in right order. So these steps use EC2 API to display expected results. Also see _setUpImageSet in test_cloud.py. Pay attention to mapping1, block_device_mapping1, _expected_bdms1 vars. Tests ensures that bdm overloads mappings for showing images. The behavior is broken by https://review.openstack.org/#/c/83805 See there in L636 of api.py: - if image_mapping: - image_defined_bdms += self._prepare_image_mapping( - instance_type, image_mapping) + if image_mapping: + image_defined_bdms += self._prepare_image_mapping( + instance_type, image_mapping) Compare with left side's L1163: - for mapping in (image_mapping, block_device_mapping): - if not mapping: - continue - self._update_block_device_mapping(context, - instance_type, instance_uuid, mapping) + for mapping in (image_mapping, block_device_mapping): + if not mapping: + continue + self._update_block_device_mapping(context, + instance_type, instance_uuid, mapping) I think it's safe to restore the old behavior. ** Description changed: If an image has settings for the same device in both 'mappings' and 'block_device_mapping' properties, the last one should be used for instance launch. But currently 'mappings' takes precedence. ============= Steps to reproduce: 1 Create a flavor with ephemeral disk. openstack flavor create m1.nano-ephemeral --id 142 --ram 64 --ephemeral 1 2 Set mapping property in an image: openstack image set --property mappings='[{"device": "vdb", "virtual": "ephemeral0"}]' cirros-0.3.4-x86_64-uec 3 Check expected mappings: euca-describe-images IMAGE ami-00000001 ... BLOCKDEVICEMAPPING /dev/vdb 3 Create a volume: openstack volume create empty --size 1 4 Create a snapshot: openstack snapshot create empty --name empty | Field | Value | | id | af84c37e-3521-435f-9976-e45aaf7fa2c7 | 5 Set bdm property in the image with the snapshot id and the same device name: openstack image set --property block_device_mapping='[{"device_name": "/dev/vdb", "boot_index": -1, "source_type": "snapshot", "destination_type": "volume", "volume_size": 1, "delete_on_termination": true, "snapshot_id": "af84c37e-3521-435f-9976-e45aaf7fa2c7"}]' --property bdm_v2=true cirros-0.3.4-x86_64-uec 6 Check expected mappings: euca-describe-images IMAGE ami-00000001 ... BLOCKDEVICEMAPPING /dev/vdb snap-00000001 1 true Here we see that bdm overloads mappings. 7 Boot an instance with the image: - nova boot --flavor m1.nano --image cirros-0.3.4-x86_64-uec inst + nova boot --flavor m1.nano-ephemeral --image cirros-0.3.4-x86_64-uec inst 8 Wait active state of the instance and view its volumes: nova show inst | Property | Value | | os-extended-volumes:volumes_attached | [] | ============= Actual result: no volume is attached to the instance. Expected result: an id of an attached volume. ============= Since Nova EC2 has not been changed for a long time, it still processes these properties in right order. So these steps use EC2 API to display expected results. Also see _setUpImageSet in test_cloud.py. Pay attention to mapping1, block_device_mapping1, _expected_bdms1 vars. Tests ensures that bdm overloads mappings for showing images. The behavior is broken by https://review.openstack.org/#/c/83805 See there in L636 of api.py: if image_mapping: image_defined_bdms += self._prepare_image_mapping( instance_type, image_mapping) Compare with left side's L1163: for mapping in (image_mapping, block_device_mapping): if not mapping: continue self._update_block_device_mapping(context, instance_type, instance_uuid, mapping) I think it's safe to restore the old behavior. -- 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/1485059 Title: bdm image property should overload 'mappings' one for instance launch Status in OpenStack Compute (nova): New Bug description: If an image has settings for the same device in both 'mappings' and 'block_device_mapping' properties, the last one should be used for instance launch. But currently 'mappings' takes precedence. ============= Steps to reproduce: 1 Create a flavor with ephemeral disk. openstack flavor create m1.nano-ephemeral --id 142 --ram 64 --ephemeral 1 2 Set mapping property in an image: openstack image set --property mappings='[{"device": "vdb", "virtual": "ephemeral0"}]' cirros-0.3.4-x86_64-uec 3 Check expected mappings: euca-describe-images IMAGE ami-00000001 ... BLOCKDEVICEMAPPING /dev/vdb 3 Create a volume: openstack volume create empty --size 1 4 Create a snapshot: openstack snapshot create empty --name empty | Field | Value | | id | af84c37e-3521-435f-9976-e45aaf7fa2c7 | 5 Set bdm property in the image with the snapshot id and the same device name: openstack image set --property block_device_mapping='[{"device_name": "/dev/vdb", "boot_index": -1, "source_type": "snapshot", "destination_type": "volume", "volume_size": 1, "delete_on_termination": true, "snapshot_id": "af84c37e-3521-435f-9976-e45aaf7fa2c7"}]' --property bdm_v2=true cirros-0.3.4-x86_64-uec 6 Check expected mappings: euca-describe-images IMAGE ami-00000001 ... BLOCKDEVICEMAPPING /dev/vdb snap-00000001 1 true Here we see that bdm overloads mappings. 7 Boot an instance with the image: nova boot --flavor m1.nano-ephemeral --image cirros-0.3.4-x86_64-uec inst 8 Wait active state of the instance and view its volumes: nova show inst | Property | Value | | os-extended-volumes:volumes_attached | [] | ============= Actual result: no volume is attached to the instance. Expected result: an id of an attached volume. ============= Since Nova EC2 has not been changed for a long time, it still processes these properties in right order. So these steps use EC2 API to display expected results. Also see _setUpImageSet in test_cloud.py. Pay attention to mapping1, block_device_mapping1, _expected_bdms1 vars. Tests ensures that bdm overloads mappings for showing images. The behavior is broken by https://review.openstack.org/#/c/83805 See there in L636 of api.py: if image_mapping: image_defined_bdms += self._prepare_image_mapping( instance_type, image_mapping) Compare with left side's L1163: for mapping in (image_mapping, block_device_mapping): if not mapping: continue self._update_block_device_mapping(context, instance_type, instance_uuid, mapping) I think it's safe to restore the old behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1485059/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp