[Gluster-devel] Plans for Gluster 3.8

[Kaushal M]

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.