Share type access references not cleaned up when share types are deleted
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Shared File Systems Service (Manila) |
Fix Released
|
Medium
|
Goutham Pacha Ravi |
Bug Description
Steps to reproduce:
1) Create a private share type:
manila type-create private-sharetype1 False --is-public False
2) Allow project1 access to private-sharetype1
manila type-access-add private-sharetype1 {project1's UUID}
3) Delete private share type:
manila type-delete private-sharetype1
4) Log into the database and check if project access still exists:
mysql> select * from share_type_projects where share_type_id='{ID of private-
+----+-
| id | created_at | updated_at | deleted_at | share_type_id | project_id | deleted |
+----+-
| 5 | 2020-04-04 09:16:38 | NULL | NULL | {ID of private-sharetype1} | {project1's UUID} | 0 |
+----+-
1 row in set (0.00 sec)
RCA: The share type deletion code does not handle cleanup for project access entries: https:/
Changed in manila: | |
importance: | Undecided → Medium |
milestone: | none → ussuri-rc1 |
Share group types suffer from the same behavior: https:/ /opendev. org/openstack/ manila/ src/commit/ 35e82746e8a6122 6a456daa8ca83ee 52e2300f36/ manila/ db/sqlalchemy/ api.py# L5079-L5101
These ghost entries cannot be cleaned up by manila or the `manila-manage db purge` tooling - will require manual intervention.