← Back to team overview

yahoo-eng-team team mailing list archive

[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