yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #36891
[Bug 1485059] [NEW] bdm image property should overload 'mappings' one for instance launch
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
Follow ups
