[openstack-dev] [manila] share dismantling policies
Csaba Henk
chenk at redhat.com
Sat Jul 11 09:33:17 UTC 2015
Just a correction of what I stated earlier...
----- Original Message -----
> From: "Csaba Henk" <chenk at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at 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
More information about the OpenStack-dev
mailing list