Suggestion for future: More granular auto-delete for snapshots. Something like a sliding window. For eg. Keep hourly snapshots for last one day, daily snapshots for the past week, weekly ones for the month etc. i.e. Tapering frequency as you go further in the past. Right now, I think it's just a total count.
On Wed, Aug 12, 2015 at 12:04 AM, 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-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
