Bug 1793245

Summary: cinder attachment-list always show empty Server ID
Product: Red Hat OpenStack Reporter: Takashi Kajinami <tkajinam>
Component: python-cinderclientAssignee: Eric Harney <eharney>
Status: CLOSED ERRATA QA Contact: Tzach Shefi <tshefi>
Severity: high Docs Contact: Chuck Copello <ccopello>
Priority: medium    
Version: 13.0 (Queens)CC: apevec, eharney, ltoscano
Target Milestone: z12Keywords: Triaged, ZStream
Target Release: 13.0 (Queens)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: python-cinderclient-3.5.0-2.el7ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-06-24 11:51:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1833118    
Bug Blocks:    

Description Takashi Kajinami 2020-01-21 00:18:38 UTC
Description of problem:

In cinder attahment-list, we see that all attachment records has empty Sever ID.
At the same time we see that cinder api returns instance information correctly,
so this is the bug in cinderclient.

~~~
(overcloud) [stack@undercloud-0 ~]$ cinder --debug --os-volume-api-version 3.50 attachment-list
...
DEBUG:keystoneauth:REQ: curl -g -i -X GET http://10.0.0.116:8776/v3/470b11ac8f90471ebef6c7f550ce76b6/attachments -H "OpenStack-API-Version: volume 3.50" -H "User-Agent: python-cinderclient" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}40dd6acdf32df3e9f9d2a7de9a550da8240102d2"
DEBUG:keystoneauth:RESP: [200] Date: Tue, 21 Jan 2020 00:14:27 GMT Server: Apache x-compute-request-id: req-7bbb807d-8ae6-4f53-a1fd-09aa9a5e2f34 OpenStack-API-Version: volume 3.50 Vary: OpenStack-API-Version,Accept-Encoding x-openstack-request-id: req-7bbb807d-8ae6-4f53-a1fd-09aa9a5e2f34 Content-Encoding: gzip Content-Length: 161 Content-Type: application/json 
RESP BODY: {"attachments": [{"status": "attached", "instance": "8f1f617d-9f8f-492d-bf02-4929d37ed298", "id": "b0b71b46-3d38-48cd-85e0-d63c72d1a5ba", "volume_id": "4f51dd40-95ef-4a5d-ba02-27f9fff62a22"}]}

DEBUG:keystoneauth:GET call to volumev3 for http://10.0.0.116:8776/v3/470b11ac8f90471ebef6c7f550ce76b6/attachments used request id req-7bbb807d-8ae6-4f53-a1fd-09aa9a5e2f34
+--------------------------------------+--------------------------------------+----------+-----------+
| ID                                   | Volume ID                            | Status   | Server ID |
+--------------------------------------+--------------------------------------+----------+-----------+
| b0b71b46-3d38-48cd-85e0-d63c72d1a5ba | 4f51dd40-95ef-4a5d-ba02-27f9fff62a22 | attached |           |
+--------------------------------------+--------------------------------------+----------+-----------+
~~~

There exists the fix[1] already merged in stable/train and master.
We should also backport it to stable branches so that we can see required information by a single command.

[1] https://review.opendev.org/#/c/658948/

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Create an instance
2. Create a volume and attach it to the instance
3. See cinder attachment-list

Actual results:
Server ID is empty

Expected results:
Server ID is shows id of the instance


Additional info:

Comment 1 Luigi Toscano 2020-02-25 11:06:26 UTC
All the backports have been merged upstream up to queens.

Comment 7 Tzach Shefi 2020-06-09 08:01:12 UTC
Verified on:
python2-cinderclient-3.5.0-2.el7ost.noarch


Booted up a few instances, attached volumes to them, this time we do see serverID column populated. 
Good to verify. 

(overcloud) [stack@undercloud-0 ~]$ cinder  --os-volume-api-version 3.50 attachment-list
+--------------------------------------+--------------------------------------+----------+--------------------------------------+
| ID                                   | Volume ID                            | Status   | Server ID                            |
+--------------------------------------+--------------------------------------+----------+--------------------------------------+
| 1ba17c6d-6042-4246-ba22-9255ee5aff54 | c55ad72f-45e8-41f7-8284-518abd8471dc | attached | 075eeac7-267f-4a15-a26b-e00e6278a3f9 |
| 7a1776ca-8ded-44a9-aa7e-d5e6717c435d | 716ee2ef-6027-4383-a687-515f734e69c1 | attached | 9ef25d7b-81cd-43be-b048-2583d0dbcb4a |
| 89587940-42c2-41e7-999e-0e5b91c0d235 | 8009fd8f-5022-423a-b810-e2e4a6405570 | attached | b2ceef75-d4fe-44fd-a3a2-6f29df36f5cb |
| 9e0300dc-cb57-4f14-820c-a592c3f64c6b | 41159565-8e32-44f0-9fb5-d7cf49c8af4a | attached | 457c6dd3-865a-4e50-8d56-6cc6f493f0e4 |
+--------------------------------------+--------------------------------------+----------+--------------------------------------+

Comment 9 errata-xmlrpc 2020-06-24 11:51:47 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:2722