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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
