<div dir="ltr"><div><div><div>Hello everyone,<br><br></div><div>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.<br></div><div><br></div><div>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 <span class="pl-en">`<span style="font-family:monospace,monospace">_remove_share_access_rules</span>` in the `</span><span style="font-family:monospace,monospace">ShareManager</span>`, 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;<br></div><a href="https://github.com/openstack/manila/blob/master/manila/share/manager.py#L600"><span class="pl-en">https://github.com/openstack/manila/blob/master/manila/share/manager.py#L600</span></a></div><div><span class="pl-en"></span></div><div><span class="pl-en"><br></span></div><span class="pl-en">I think an acceptable fix to this would be to wrap the `</span><span style="font-family:monospace,monospace">_deny_access</span>` call with a `<span style="font-family:monospace,monospace">try</span>`... `<span style="font-family:monospace,monospace">except</span>` 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.<br></div><div><br></div><div>This got my attention after running the tempest integration tests, where the teardown <i>sometimes</i> fails in <span style="font-family:monospace,monospace">tempest.api.share.test_rules:ShareIpRulesForNFSTest</span>.<br><br>Any thoughts on this? Perhaps there is a smoother approach that I'm not seeing.<br><br><br></div><div>Cheers,<br></div><div>Björn<br></div></div>