[Gluster-users] [Gluster-devel] Plans for Gluster 3.8

[Prasanna Kalever]

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 at gmail.com>
To: "Kaushal M" <kshlmster at gmail.com>
Cc: "Csaba Henk" <chenk at redhat.com>, gluster-users at gluster.org, "Gluster Devel" <gluster-devel at gluster.org>
Sent: Thursday, August 13, 2015 8:58:20 PM
Subject: Re: [Gluster-users] [Gluster-devel] 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 at gmail.com > 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 at gluster.org 
http://www.gluster.org/mailman/listinfo/gluster-devel 

_______________________________________________
Gluster-users mailing list
Gluster-users at gluster.org
http://www.gluster.org/mailman/listinfo/gluster-users