Reporter didn't provide a version. Using the latest from master, I was not able to reproduce this issue (see below). Since the reporter mentioned that Cinder does not know about this false attachment, but Nova does, I would bet something is being set on the Nova side.
ubuntu@mount-issue:~/devstack$ nova list c+--------------------------------------+---------+--------+------------+-------------+------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+---------+--------+------------+-------------+------------------+ | 57304c45-101d-4ce0-8f4b-6b7ad853d135 | server1 | ACTIVE | - | Running | private=10.0.0.2 | | 1cb270bd-2131-42fa-9f99-ed95cd077cde | server2 | ACTIVE | - | Running | private=10.0.0.3 | +--------------------------------------+---------+--------+------------+-------------+------------------+ iubuntu@mount-issue:~/devstack$ cinder list +--------------------------------------+-----------+------+------+-------------+----------+-------------+ | ID | Status | Name | Size | Volume Type | Bootable | Attached to | +--------------------------------------+-----------+------+------+-------------+----------+-------------+ | 2a57f161-0828-4b68-8f93-cd4493ff725b | available | None | 1 | lvmdriver-1 | false | | +--------------------------------------+-----------+------+------+-------------+----------+-------------+ ubuntu@mount-issue:~/devstack$ nova volume-attach server1 2a57f161-0828-4b68-8f93-cd4493ff725b +----------+--------------------------------------+ | Property | Value | +----------+--------------------------------------+ | device | /dev/vdb | | id | 2a57f161-0828-4b68-8f93-cd4493ff725b | | serverId | 57304c45-101d-4ce0-8f4b-6b7ad853d135 | | volumeId | 2a57f161-0828-4b68-8f93-cd4493ff725b | +----------+--------------------------------------+ ubuntu@mount-issue:~/devstack$ nova volume-attach server2 2a57f161-0828-4b68-8f93-cd4493ff725b ERROR (BadRequest): Invalid volume: volume '2a57f161-0828-4b68-8f93-cd4493ff725b' status must be 'available'. Currently in 'in-use' (HTTP 400) (Request-ID: req-bfa40f00-56f9-4535-a4d1-23a8cb69b908) ubuntu@mount-issue:~/devstack$ nova volume-attach server2 2a57f161-0828-4b68-8f93-cd4493ff725b ERROR (BadRequest): Invalid volume: volume '2a57f161-0828-4b68-8f93-cd4493ff725b' status must be 'available'. Currently in 'in-use' (HTTP 400) (Request-ID: req-83736950-ff20-4d93-b512-ab7ffc25c7bc) ubuntu@mount-issue:~/devstack$ cinder list +--------------------------------------+--------+------+------+-------------+----------+--------------------------------------+ | ID | Status | Name | Size | Volume Type | Bootable | Attached to | +--------------------------------------+--------+------+------+-------------+----------+--------------------------------------+ | 2a57f161-0828-4b68-8f93-cd4493ff725b | in-use | None | 1 | lvmdriver-1 | false | 57304c45-101d-4ce0-8f4b-6b7ad853d135 | +--------------------------------------+--------+------+------+-------------+----------+--------------------------------------+ ubuntu@mount-issue:~/devstack$ http http://localhost:8774/v2/b9903b32e6e94a5ab2ee40e217be0fab/servers/1cb270bd-2131-42fa-9f99-ed95cd077cde/os-volume_attachments X-Auth-Token:'e08bc40fd5f148cf817f99c1133da8aa' HTTP/1.1 200 OK Content-Length: 25 Content-Type: application/json Date: Fri, 02 Jan 2015 18:37:27 GMT X-Compute-Request-Id: req-5d213be2-60af-450a-b521-8f979d5a80e6 { "volumeAttachments": [] } ** Also affects: nova Importance: Undecided Status: New ** Changed in: cinder Status: Confirmed => Invalid ** Changed in: cinder Status: Invalid => Incomplete -- 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/1398588 Title: volume_attach action registers volume attachment even on failure Status in Cinder: Incomplete Status in OpenStack Compute (Nova): New Bug description: When attaching volumes to instances, if the volume attachment fails, it is still noted as successful by the system in some cases. This is the information reflected when requesting the details of a servers volume attachments http://developer.openstack.org/api-ref-compute-v2-ext.html /v2/{tenant_id}/servers/{server_id}/os-volume_attachments Show volume attachment details In the example, I have 2 test servers and 1 test volume. I attach the volume to test_server1 and it is successful (though please see: https://bugs.launchpad.net/cinder/+bug/1398583) Next, I try to attach the same volume to test_server2. This call fails as expected, but the mountpoint / attachment is still registered. To demonstrate, I repeat the previous call. It fails again, but this time due to the requested mountpoint being in-use vs. the volume being attached. I next make a call to list the volume attachments for test_server2. It lists volume attachments even though there are none and the Cinder api server does not register this. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1398588/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
