Volume_Attachment_ID uses Volume_ID

[Maurice Escher]

Version: Kilo Stable

Problem Description: querying nova for volume attachments returns the wrong volume_attachment_id.
I receive the volume_id instead of the volume_attachment_id.

Example:

curl -g -H "X-Auth-Token: $ADMIN_TOKEN" -X GET https://compute:8774/v2/(tenant_id)/servers/56293904-9384-48f8-9329-c961056583f1/os-volume_attachments

{"volumeAttachments": [{"device": "/dev/vdb", "serverId": "56293904-9384-48f8-9329-c961056583f1", "id": "a75bec42-77b5-42ff-90e5-e505af14b84a", "volumeId": "a75bec42-77b5-42ff-90e5-e505af14b84a"}]}

Having a look at the database directly, I see the real volume_attachment_id:

select (id, volume_id, instance_uuid) from volume_attachment where volume_id='a75bec42-77b5-42ff-90e5-e505af14b84a';

(9cb82021-e77e-495f-8ade-524bc5ccf68c,a75bec42-77b5-42ff-90e5-e505af14b84a,56293904-9384-48f8-9329-c961056583f1)

Cinder API gets it right, though.

Further Impact:
Horizon uses the returned volume_attachment_id to query for volume_details.
That is wrong and only works now because of the broken nova behaviour.

[Davanum Srinivas (DIMS) (dims-v)]

Cinder API gets it right *because* "volume_attachment" is a cinder table :) right?

[Markus Zoeller (markus_z) (mzoeller)]

This would have impact on the documentation too. Currently the apiref [1] also shows two identical UUIDs for "id" and "volumeId".

[1] http://developer.openstack.org/api-ref-compute-v2-ext.html#listVolumeAttachments

[Zhihai Song (szhsong)]

The 'id' in the block_device_mapping table is sequential numbers, not some randomly generated uuid. Where will this 'id' be used?
However, os-volume_attachments shouldn't return the volume_id in the place of 'id'.

[Matt Riedemann (mriedem)]

It looks like this is intentional:

https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/volumes.py#L203

That might just be from the create call though, since the attach is async the response in the POST is the volume_id since we don't know the attachment ID. We should be able to know that in the GET though.

[Matt Riedemann (mriedem)]

In the case of GET, nova-api only gets the block_device_mapping information for the given instance and volume, it doesn't actually call off to cinder to get the attachment information:

https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/volumes.py#L264

So the only way to know the attachment ID is if it's stored in the BlockDeviceMapping object. And we don't have the attachment_id in the BDM object today:

https://github.com/openstack/nova/blob/master/nova/objects/block_device.py#L63

That's not to say it couldn't be added, but it'd be an objects version change and an API change to show it - so this would require a microversion for the nova API and requires a blueprint and spec.

[Matt Riedemann (mriedem)]

Given our policy on no more API proxies to other services, I'm inclined to mark this as 'won't fix':

http://docs.openstack.org/developer/nova/project_scope.html#no-more-api-proxies

You can get the attachment id from the volume API.

[Wenzhi Yu (yuywz)]

Hi Matt,

I think using volume.id as volume_attachment.id will make confusion, especially for cloud admin. I agree on "no more API proxies to other services" but return a "wrong" value in API response can't be appropriate(even leave the 'id' field as None seems to be more reasonable to me).

I've drafted a spec for this bug, please review:
https://review.openstack.org/#/c/214021/

[OpenStack Infra (hudson-openstack)]

Change abandoned by John Garbutt (<email address hidden>) on branch: master
Review: https://review.openstack.org/214021
Reason: This one seems suck, please use the usual channels to resolve that.