yahoo-eng-team team mailing list archive

[Maurice Schreiber <maurice.schreiber@xxxxxxx>]

Public bug reported:

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.

** Affects: nova
     Importance: Undecided
         Status: New

-- 
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/1480131

Title:
  Volume_Attachment_ID uses Volume_ID

Status in OpenStack Compute (nova):
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1480131/+subscriptions