Open Stack

Hello everyone,

this is my first thread on this mailing list, and I would like to take the
opportunity to say that it was great to see you all at the midcycle, even
if remote.

Now, to my question; I've been looking into an issue that arise when
deleting access to a share, and then momentarily after, deleting the same
share. The delete fails due to a race in `_remove_share_access_rules` in
the `ShareManager`, which attempts to delete all granted permissions on the
share before removing it, but one of the access permissions is concurrently
deleted due to the first API call, see;
https://github.com/openstack/manila/blob/master/manila/share/manager.py#L600

I think an acceptable fix to this would be to wrap the `_deny_access` call
with a `try`... `except` block, and log any attempts to remove non-existing
permissions. The problem is that there seems to be no contract on the
exception to throw in case you attempt to delete an `access` which does not
exist -- each driver behaves differently.

This got my attention after running the tempest integration tests, where
the teardown *sometimes* fails in
tempest.api.share.test_rules:ShareIpRulesForNFSTest.

Any thoughts on this? Perhaps there is a smoother approach that I'm not
seeing.


Cheers,
Björn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150820/c51abc0f/attachment.html>