[Gluster-users] Proposal to mark few features as Deprecated / SunSet from Version 5.0
Hans Henrik Happe
happe at nbi.dk
Tue Mar 19 14:12:15 UTC 2019
On 19/03/2019 14.10, Amar Tumballi Suryanarayan wrote:
> Hi Hans,
>
> Thanks for the honest feedback. Appreciate this.
>
> On Tue, Mar 19, 2019 at 5:39 PM Hans Henrik Happe <happe at nbi.dk
> <mailto:happe at nbi.dk>> wrote:
>
> Hi,
>
> Looking into something else I fell over this proposal. Being a
> shop that are going into "Leaving GlusterFS" mode, I thought I
> would give my two cents.
>
> While being partially an HPC shop with a few Lustre filesystems,
> we chose GlusterFS for an archiving solution (2-3 PB), because we
> could find files in the underlying ZFS filesystems if GlusterFS
> went sour.
>
> We have used the access to the underlying files plenty, because of
> the continuous instability of GlusterFS'. Meanwhile, Lustre have
> been almost effortless to run and mainly for that reason we are
> planning to move away from GlusterFS.
>
> Reading this proposal kind of underlined that "Leaving GluserFS"
> is the right thing to do. While I never understood why GlusterFS
> has been in feature crazy mode instead of stabilizing mode, taking
> away crucial features I don't get. With RoCE, RDMA is getting
> mainstream. Quotas are very useful, even though the current
> implementation are not perfect. Tiering also makes so much sense,
> but, for large files, not on a per-file level.
>
>
> It is a right concern to raise, and removing the existing features is
> not a good thing most of the times. But, one thing we noticed over the
> years is, the features which we develop, and not take to completion
> cause the major heart-burn. People think it is present, and it is
> already few years since its introduced, but if the developers are not
> working on it, users would always feel that the product doesn't work,
> because that one feature didn't work.
>
> Other than Quota in the proposal email, for all other features, even
> though we have *some* users, we are inclined towards deprecating them,
> considering projects overall goals of stability in the longer run.
>
>
> To be honest we only use quotas. We got scared of trying out new
> performance features that potentially would open up a new back of
> issues.
>
> About Quota, we heard enough voices, so we will make sure we keep it.
> The original email was 'Proposal', and hence these opinions matter for
> decision.
>
> Sorry for being such a buzzkill. I really wanted it to be different.
>
> We hear you. Please let us know one thing, which were the versions you
> tried ?
>
We started at 3.6 4 years ago. Now we are at 3.12.15, working towards
moving to 4.1.latest.
> We hope in coming months, our recent focus on Stability and Technical
> debt reduction will help you to re-look at Gluster after sometime.
That's great to hear.
>
> Cheers,
> Hans Henrik
>
> On 19/07/2018 08.56, Amar Tumballi wrote:
>> *
>>
>> Hi all,
>>
>> Over last 12 years of Gluster, we have developed many features,
>> and continue to support most of it till now. But along the way,
>> we have figured out better methods of doing things. Also we are
>> not actively maintaining some of these features.
>>
>> We are now thinking of cleaning up some of these ‘unsupported’
>> features, and mark them as ‘SunSet’ (i.e., would be totally taken
>> out of codebase in following releases) in next upcoming release,
>> v5.0. The release notes will provide options for smoothly
>> migrating to the supported configurations.
>>
>> If you are using any of these features, do let us know, so that
>> we can help you with ‘migration’.. Also, we are happy to guide
>> new developers to work on those components which are not actively
>> being maintained by current set of developers.
>>
>>
>> List of features hitting sunset:
>>
>>
>> ‘cluster/stripe’ translator:
>>
>> This translator was developed very early in the evolution of
>> GlusterFS, and addressed one of the very common question of
>> Distributed FS, which is “What happens if one of my file is
>> bigger than the available brick. Say, I have 2 TB hard drive,
>> exported in glusterfs, my file is 3 TB”. While it solved the
>> purpose, it was very hard to handle failure scenarios, and give a
>> real good experience to our users with this feature. Over the
>> time, Gluster solved the problem with it’s ‘Shard’ feature, which
>> solves the problem in much better way, and provides much better
>> solution with existing well supported stack. Hence the proposal
>> for Deprecation.
>>
>> If you are using this feature, then do write to us, as it needs a
>> proper migration from existing volume to a new full supported
>> volume type before you upgrade.
>>
>>
>> ‘storage/bd’ translator:
>>
>> This feature got into the code base 5 years back with this patch
>> <http://review.gluster.org/4809>[1]. Plan was to use a block
>> device directly as a brick, which would help to handle disk-image
>> storage much easily in glusterfs.
>>
>> As the feature is not getting more contribution, and we are not
>> seeing any user traction on this, would like to propose for
>> Deprecation.
>>
>> If you are using the feature, plan to move to a supported gluster
>> volume configuration, and have your setup ‘supported’ before
>> upgrading to your new gluster version.
>>
>>
>> ‘RDMA’ transport support:
>>
>> Gluster started supporting RDMA while ib-verbs was still new, and
>> very high-end infra around that time were using Infiniband.
>> Engineers did work with Mellanox, and got the technology into
>> GlusterFS for better data migration, data copy. While current day
>> kernels support very good speed with IPoIB module itself, and
>> there are no more bandwidth for experts in these area to maintain
>> the feature, we recommend migrating over to TCP (IP based)
>> network for your volume.
>>
>> If you are successfully using RDMA transport, do get in touch
>> with us to prioritize the migration plan for your volume. Plan is
>> to work on this after the release, so by version 6.0, we will
>> have a cleaner transport code, which just needs to support one type.
>>
>>
>> ‘Tiering’ feature
>>
>> Gluster’s tiering feature which was planned to be providing an
>> option to keep your ‘hot’ data in different location than your
>> cold data, so one can get better performance. While we saw some
>> users for the feature, it needs much more attention to be
>> completely bug free. At the time, we are not having any active
>> maintainers for the feature, and hence suggesting to take it out
>> of the ‘supported’ tag.
>>
>> If you are willing to take it up, and maintain it, do let us
>> know, and we are happy to assist you.
>>
>> If you are already using tiering feature, before upgrading, make
>> sure to do gluster volume tier detachall the bricks before
>> upgrading to next release. Also, we recommend you to use features
>> like dmcacheon your LVM setup to get best performance from bricks.
>>
>>
>> ‘Quota’
>>
>> This is a call out for ‘Quota’ feature, to let you all know that
>> it will be ‘no new development’ state. While this feature is
>> ‘actively’ in use by many people, the challenges we have in
>> accounting mechanisms involved, has made it hard to achieve good
>> performance with the feature. Also, the amount of extended
>> attribute get/set operations while using the feature is not very
>> ideal. Hence we recommend our users to move towards setting quota
>> on backend bricks directly (ie, XFS project quota), or to use
>> different volumes for different directories etc.
>>
>> As the feature wouldn’t be deprecated immediately, the feature
>> doesn’t need a migration plan when you upgrade to newer version,
>> but if you are a new user, we wouldn’t recommend setting quota
>> feature. By the release dates, we will be publishing our best
>> alternatives guide for gluster’s current quota feature.
>>
>> Note that if you want to contribute to the feature, we have
>> project quota based issue open
>> <https://github.com/gluster/glusterfs/issues/184>[2] Happy to get
>> contributions, and help in getting a newer approach to Quota.
>>
>>
>> ------------------------------------------------------------------------
>>
>> These are our set of initial features which we propose to take
>> out of ‘fully’ supported features. While we are in the process of
>> making the user/developer experience of the project much better
>> with providing well maintained codebase, we may come up with few
>> more set of features which we may possibly consider to move out
>> of support, and hence keep watching this space.
>>
>> [1] - http://review.gluster.org/4809
>>
>> [2] - https://github.com/gluster/glusterfs/issues/184
>>
>> Regards,
>>
>> Vijay, Shyam, Amar
>>
>> *
>>
>>
>>
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
>> https://lists.gluster.org/mailman/listinfo/gluster-users
>
>
>
> --
> Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20190319/eea19454/attachment.html>
More information about the Gluster-users
mailing list