yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #59948
[Bug 1644725] Re: Check destination_type when booting with bdm provided
** Also affects: python-openstackclient
Importance: Undecided
Status: New
** Changed in: python-openstackclient
Assignee: (unassigned) => Zhenyu Zheng (zhengzhenyu)
** No longer affects: python-openstackclient
--
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/1644725
Title:
Check destination_type when booting with bdm provided
Status in Cinder:
New
Status in OpenStack Compute (nova):
In Progress
Status in python-novaclient:
In Progress
Bug description:
When booting instance with block_device_mapping provided, in the
current implementation, the "destination_type" is allowed to be None,
and this lead to un-sync between Nova and Cinder:
Step 1: Booting with block_device_mapping, leave destination_type to
be None:
root@SZX1000191849:/var/log/nova# nova --debug boot --flavor 1
--image 2ba75018-403f-407b-864a-08564022e1f8 --nic net-
id=cce1d2f1-acf4-4646-abdc-069f8d0dbb71 --block-device
'source=volume,id=9f49d5b0-3625-46a2-9ed4-d82f19949148' test_bdm
the corresponding REST call is:
DEBUG (session:342) REQ: curl -g -i -X POST http://10.229.45.17:8774/v2.1/os-volumes_boot -H "Accept: application/json" -H "User-Agent: python-novaclient" -H "OpenStack-API-Version: compute 2.37" -H "X-OpenStack-Nova-API-Version: 2.37" -H "X-Auth-Token: {SHA1}4d8c2c43338e1c4d96e08bcd1c2f3ff36de14154" -H "Content-Type: application/json" -d '{"server": {"name": "test_bdm", "imageRef": "2ba75018-403f-407b-864a-08564022e1f8", "block_device_mapping_v2": [{"source_type": "image", "delete_on_termination": true, "boot_index": 0, "uuid": "2ba75018-403f-407b-864a-08564022e1f8", "destination_type": "local"}, {"source_type": "volume", "uuid": "9f49d5b0-3625-46a2-9ed4-d82f19949148"}], "flavorRef": "1", "max_count": 1, "min_count": 1, "networks": [{"uuid": "cce1d2f1-acf4-4646-abdc-069f8d0dbb71"}]}}'
Step 2: After the instance is successfully launched, the detailed info
is like this:
root@SZX1000191849:/var/log/nova# nova show 83d9ec32-93e0-441a-ae10-00e08b65de0b
+--------------------------------------+----------------------------------------------------------------------------------+
| Property | Value |
+--------------------------------------+----------------------------------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-SRV-ATTR:host | SZX1000191849 |
| OS-EXT-SRV-ATTR:hostname | test-bdm |
| OS-EXT-SRV-ATTR:hypervisor_hostname | SZX1000191849 |
| OS-EXT-SRV-ATTR:instance_name | instance-00000016 |
| OS-EXT-SRV-ATTR:kernel_id | 87c9afd6-3a47-4a4c-a804-6b456d68136d |
| OS-EXT-SRV-ATTR:launch_index | 0 |
| OS-EXT-SRV-ATTR:ramdisk_id | acd02b28-6484-4f90-a5e7-bba7159343e1 |
| OS-EXT-SRV-ATTR:reservation_id | r-fiqwkq02 |
| OS-EXT-SRV-ATTR:root_device_name | /dev/vda |
| OS-EXT-SRV-ATTR:user_data | - |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-STS:task_state | - |
| OS-EXT-STS:vm_state | active |
| OS-SRV-USG:launched_at | 2016-11-25T06:50:36.000000 |
| OS-SRV-USG:terminated_at | - |
| accessIPv4 | |
| accessIPv6 | |
| config_drive | |
| created | 2016-11-25T06:50:30Z |
| description | - |
| flavor | m1.tiny (1) |
| hostId | 410c49382deba8e205044b231169b2a656b27b6c994815366712b62e |
| host_status | UP |
| id | 83d9ec32-93e0-441a-ae10-00e08b65de0b |
| image | cirros-0.3.4-x86_64-uec (2ba75018-403f-407b-864a-08564022e1f8) |
| key_name | - |
| locked | False |
| metadata | {} |
| name | test_bdm |
| os-extended-volumes:volumes_attached | [{"id": "9f49d5b0-3625-46a2-9ed4-d82f19949148", "delete_on_termination": false}] |
| private network | 2001:db8:8000::5, 10.0.0.13 |
| progress | 0 |
| security_groups | default |
| status | ACTIVE |
| tags | [] |
| tenant_id | 405a8b8100ae47ffaa89730681ee400f |
| updated | 2016-11-25T06:50:36Z |
| user_id | 43db6c7e51754c0d8c8b87278144f789 |
+--------------------------------------+----------------------------------------------------------------------------------+
As been shown, a volume attach is recored in Nova
Step 3: Check the volume status in Cinder:
root@SZX1000191849:/var/log/nova# cinder list
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
| 9f49d5b0-3625-46a2-9ed4-d82f19949148 | available | - | 1 | lvmdriver-1 | false | |
+--------------------------------------+-----------+------+------+-------------+----------+-------------+
The volume is still available.
The volume is actually not attached by checking the instance's XML.
We should forrbid the boot call with None destination_type both in Nova and NovaClient.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1644725/+subscriptions
References
