[Gluster-devel] [Gluster-users] Proposal to mark few features as Deprecated / SunSet from Version 5.0

Mon Jul 23 16:21:32 UTC 2018

On Mon, Jul 23, 2018 at 8:21 PM, Gudrun Mareike Amedick <
g.amedick at uni-luebeck.de> wrote:

> Hi,
>
> we're planning a dispersed volume with at least 50 project directories.
> Each of those has its own quota ranging between 0.1TB and 200TB. Comparing
> XFS
> project quotas over several servers and bricks to make sure their total
> matches the desired value doesn't really sound practical. It would probably
> be
> possible to create and maintain 50 volumes and more, but it doesn't seem
> to be a desirable solution. The quotas aren't fixed and resizing a volume is
> not as trivial as changing the quota.
>
> Quota was in the past and still is a very comfortable way to solve this.
>
> But what is the new recommended way for such a setting when the quota is
> going to be deprecated?
>
>
Thanks for the feedback. Helps us to prioritize. Will get back on this.

-Amar

> Kind regards
>
> Gudrun
> Am Donnerstag, den 19.07.2018, 12:26 +0530 schrieb Amar Tumballi:
> > 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[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 detach all the bricks before upgrading to next
> > release. Also, we recommend you to use features like dmcache on 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[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
> > 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-devel/attachments/20180723/0017eb0a/attachment-0001.html>