Just a correction of what I stated earlier... ----- Original Message ----- > From: "Csaba Henk" <ch...@redhat.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Sent: Thursday, July 9, 2015 3:13:29 PM > Subject: Re: [openstack-dev] [manila] share dismantling policies ... > Sure, Manila cannot force the users to unmount the volume, but it *can* > render the mount unusable (ending up in a state whereby all system calls > to the mount fail). That's what generic driver -- and any driver with > kNFS as export mechanism -- does (disruptive access control). However, as > we found out, a user mount with glusterfs_native will remain usable after > access to share is revoked (non-disruptive access control). So ATM there is > no > uniformity in access control disruptiveness across the drivers.
With respect to gluster_native: "a user mount with glusterfs_native will remain usable after access to share is revoked" is not true. glusterfs_native does comply with the access deny requirements as laid down by Ben in another mail of this thread[1]. The correct statement is: we were experimenting with some optimizations for glusterfs_native through which we ended up with a modification that had the effect of leaving user mounts with glusterfs_native usable after access to share was revoked. TL;DR: glusterfs_native is OK. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069109.html Csaba __________________________________________________________________________ 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
