Bug 1362233

Summary: CephFS Native Manila Driver Delete Hangs when Using Manila Cephx ID for Mounting Share to Nova Instance
Product: Red Hat OpenStack Reporter: Dustin Schoenbrun <dschoenb>
Component: openstack-manilaAssignee: Dustin Schoenbrun <dschoenb>
Status: CLOSED ERRATA QA Contact: Dustin Schoenbrun <dschoenb>
Severity: medium Docs Contact: Don Domingo <ddomingo>
Priority: unspecified    
Version: 9.0 (Mitaka)CC: apevec, jschluet, lhh, rraja, tbarron
Target Milestone: asyncKeywords: ZStream
Target Release: 9.0 (Mitaka)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-manila-2.0.0-6.el7ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-05 19:13:02 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:

Description Dustin Schoenbrun 2016-08-01 16:03:27 UTC 
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.

Version-Release number of selected component (if applicable):
python-manilaclient-1.8.1-1.el7ost.noarch

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.
Comment 4 errata-xmlrpc 2016-10-05 19:13:02 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://rhn.redhat.com/errata/RHBA-2016-2033.html