yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #66238
[Bug 1644725] Re: Check destination_type when booting with bdm provided
It does feel like it might be better to fix this on the client side.
Marking as opinion as the patch author abandoned the nova patch. It is
welcome to come back later.
** Changed in: nova
Status: New => Opinion
--
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):
Opinion
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
