v3 attachment_delete does not delete record from db

[Steve Noyes]

While testing migration using the new v3 cinder attach apis, I noticed that attachment records in the table volume_attachment are not removed when an attachment_delete is done. Is it supposed to work like this?

Here is a case where I did a detach from nova using attachment-delete of attachment 2fddf0a4-d98b-4ffa-900c-222138830d49:

2017-06-03 09:45:03.852 DEBUG cinder.volume.manager req-3fe4f27c-11a0-4844-9d3b-3cbd446ee8c8 ^[[00;36mdemo None^[[00;32m] ^[[01;35m^[[00;32mDeleting attachment 2fddf0a4-d98b-4ffa-900c-222138830d49.^[[00m ^[[00;33mfrom (pid=25206) _do_attachment_delete /opt/stack/cinder/cinder/volume/manager.py:4130^[[00m

Afterwards, the attach record is still there:

mysql> select * from volume_attachment;
...
| 2017-06-03 13:43:59 | 2017-06-03 13:44:03 | 2017-06-03 13:45:04 | 1 | 2fddf0a4-d98b-4ffa-900c-222138830d49 | f84e32ed-fed5-4a84-a448-64c406db145b | ub16-dstack-ctl1 | 00181b03-c7cf-43e3-a864-7c40ad52dda0 | na | 2017-06-03 13:44:03 | 2017-06-03 13:45:04 | rw | detached | {"access_mode": "rw", "attachment_id": "2fddf0a4-d98b-4ffa-900c-222138830d49", "target_discovered": "False", "encrypted": "False", "driver_volume_type": "iscsi", "qos_specs": null, "target_iqn": "iqn.2010-10.org.openstack:volume-f84e32ed-fed5-4a84-a448-64c406db145b", "target_portal": "192.168.0.181:3260", "volume_id": "f84e32ed-fed5-4a84-a448-64c406db145b", "target_lun": "1", "auth_password": "dfHZa2JK8qJMr6KL", "auth_username": "WNZ765xNLLj4m3X3ny7o", "auth_method": "CHAP"} |
...
1 row in set (0.00 sec)

[TommyLike (hu-husheng)]

Usually cinder will not remove the record from table directly when you delete the record via CLI or API, so do you mind to confirm the deleted record's column 'deleted' is whether set to 'True'? That is how we delete the record.

[John Griffith (john-griffith)]

As TommyLike pointed out, we don't actually remove the entry until a purge is done later; but you should see the deleted status set to true. If you're not seeing that there's a bug somewhere in the LM path that isn't performing the attachment-delete correctly (I think).

[Steve Noyes (steve-noyes)]

Yes, the deleted status is true (1) for deleted attachments. So I will close this out.