Hi Athin :) I shall take Bug 1245380 [RFE] Render all mounts of a volume defunct upon access revocation https://bugzilla.redhat.com/show_bug.cgi?id=1245380 Thanks & Regards, Prasanna Kumar K. ----- Original Message ----- From: "Atin Mukherjee" <atin.mukherjee83@xxxxxxxxx> To: "Kaushal M" <kshlmster@xxxxxxxxx> Cc: "Csaba Henk" <chenk@xxxxxxxxxx>, gluster-users@xxxxxxxxxxx, "Gluster Devel" <gluster-devel@xxxxxxxxxxx> Sent: Thursday, August 13, 2015 8:58:20 PM Subject: Re: [Gluster-users] Plans for Gluster 3.8 Can we have some volunteers of these BZs? -Atin Sent from one plus one On Aug 12, 2015 12:34 PM, "Kaushal M" < kshlmster@xxxxxxxxx > wrote: Hi Csaba, These are the updates regarding the requirements, after our meeting last week. The specific updates on the requirements are inline. In general, we feel that the requirements for selective read-only mode and immediate disconnection of clients on access revocation are doable for GlusterFS-3.8. The only problem right now is that we do not have any volunteers for it. > 1. Bug 829042 - [FEAT] selective read-only mode > https://bugzilla.redhat.com/show_bug.cgi?id=829042 > > absolutely necessary for not getting tarred & feathered in Tokyo ;) > either resurrect http://review.gluster.org/3526 > and _find out integration with auth mechanism for special > mounts_, or come up with a completely different concept > With the availability of client_t, implementing this should become easier. The server xlator would store the incoming connections common name or address in the client_t associated with the connection. The read-only xlator could then make use of this information to selectively allow read-only clients. The read-only xlator would need to implement a new option for selective read-only, which would be populated with lists of common-names and addresses of clients which would get read-only access. > 2. Bug 1245380 - [RFE] Render all mounts of a volume defunct upon access revocation > https://bugzilla.redhat.com/show_bug.cgi?id=1245380 > > necessary to let us enable a watershed scalability > enhancement > Currently, when auth.allow/reject and auth.ssl-allow options are changed, the server xlator does a reconfigure to reload its access list. It just does a reload, and doesn't affect any existing connections. To bring this feature in, the server xlator would need to iterate through its xprt_list and check every connection for authorization again on a reconfigure. Those connections which have lost authorization would be disconnected. > 3. Bug 1226776 – [RFE] volume capability query > https://bugzilla.redhat.com/show_bug.cgi?id=1226776 > > eventually we'll be choking in spaghetti if we don't get > this feature. The ugly version checks we need to do against > GlusterFS as in > > https://review.openstack.org/gitweb?p=openstack/manila.git;a=commitdiff;h=29456c#patch3 > > will proliferate and eat the guts of the code out of its > living body if this is not addressed. > This requires some more thought to figure out the correct solution. One possible way to get the capabilities of the cluster would be to look at the clusters running op-version. This can be obtained using `gluster volume get all cluster.op-version` (the volume get command is available in glusterfs-3.6 and above). But this doesn't provide much improvement over the existing checks being done in the driver. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
