Description of problem:
When you use the same Cephx ID to mount the Manila share created by the CephFS Native Driver as what Manila uses to communicate with the underlying Ceph cluster the delete share operation will silently fail and the share will be put into a permanent "deleting" status. This is because the client fails to check if the Cephx ID being used is the same that the Manila services are using to communicate with the underlying Ceph cluster.
How reproducible:
100%
Steps to Reproduce:
1. Set up and configure Manila to use the CephFS Native driver.
2. Create a Manila share.
3. Grant access to the share using the same Cephx ID that the Manila service uses to communicate with the Ceph backend.
4. Delete the share that was created in step 2.
5. Observe that the share is now stuck in "deleting" status and that no entries were made in the scheduler or share logs.
Actual results:
When you attempt to delete the share that has an access rule that specifies the same Cephx ID as Manila uses to communicate with the Ceph backend the share becomes stuck in the "deleting" state.
Expected results:
The Manila Client should not allow access rules to be created using the same Cephx ID as what the Manila services use to communicate with the Ceph backend.
Additional info:
Note that cleaning up the share after being stuck in the deleting state involves deleting the access rule from the Manila database and then force-deleting the share.
Dustin, should we move this bug to manila's LP?