[Gluster-devel] Plans for Gluster 3.8
atin.mukherjee83 at gmail.com
Thu Aug 13 15:28:20 UTC 2015
Can we have some volunteers of these BZs?
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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel