Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1362233 - CephFS Native Manila Driver Delete Hangs when Using Manila Cephx ID for Mounting Share to Nova Instance
Summary: CephFS Native Manila Driver Delete Hangs when Using Manila Cephx ID for Mount...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-manila
Version: 9.0 (Mitaka)
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: async
: 9.0 (Mitaka)
Assignee: Dustin Schoenbrun
QA Contact: Dustin Schoenbrun
Don Domingo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-01 16:03 UTC by Dustin Schoenbrun
Modified: 2016-10-05 19:13 UTC (History)
5 users (show)

Fixed In Version: openstack-manila-2.0.0-6.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-05 19:13:02 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
OpenStack gerrit 349718 None None None 2016-08-02 16:47:16 UTC
OpenStack gerrit 363118 None None None 2016-08-30 19:26:57 UTC
Launchpad 1608592 None None None 2016-08-01 16:03:27 UTC
Red Hat Product Errata RHBA-2016:2033 normal SHIPPED_LIVE Red Hat OpenStack Platform 9 Bug Fix and Enhancement Advisory 2016-10-05 23:11:29 UTC

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


Note You need to log in before you can comment on or make changes to this bug.