Is the project still alive? #4324
Replies: 16 comments 1 reply
-
The Red Hat Gluster Storage is based on upstream Gluster 6.x. Gluster 6.x is already EOL on 12th May 2020 (Ref: https://www.gluster.org/release-schedule/). Only Red Hat customers are affected with RHGS EOL. Gluster community affected by Red Hat's decision to stop their Gluster based product? Yes. It will definitely impact the Gluster development but the project may not die since there are many maintainers and developers contributing to Gluster outside the Red Hat. Feature development and the bug fixes may slow down, but I think (and I hope) the project will continue in slow pace. -- |
Beta Was this translation helpful? Give feedback.
-
I'm completely agreed about the main point RHGS is different from Community, but ff course RH was one of the major developers on the project also because they bought it.
🤞🏻 |
Beta Was this translation helpful? Give feedback.
-
While most of this is true, the actual maintainers and those responsible for implementing bug fixes and feature updates are nearly all Red Hat employees. So there's a very legitimate concern that this project will stagnant or get pillaged and then made proprietary. Oh yes, just like your company is doing right now. No? So yes, the phenomenon of leveraging the GPL to essentially take OSS and then close it off for profit is clearly GlusterFS's future. |
Beta Was this translation helpful? Give feedback.
-
@anon314159 , you've joined Github just a month ago, and all you did was raise accusations against two open source projects, GlusterFS and LizardFS (lizardfs/lizardfs#936 ). How about positively contributing to the community instead? |
Beta Was this translation helpful? Give feedback.
-
Where are you seeing my company selling Gluster based proprietary product? At Kadalu Technologies, we offer Gluster Consultancy, Feature development and the stable packages. All the fixes/enhancements are contributed back to the main project itself. We also have couple of projects based on Gluster core file system (Ex: Kadalu Storage for Kubernetes, Kadalu Storage for non-k8s deployments). All projects/products based on GlusterFS are Open Source. Please clarify where we are closing the source and selling it. |
Beta Was this translation helpful? Give feedback.
-
GlusterFS is licensed under GPLv3 (Not BSD). A simple search would have shown you that one cannot close the source. |
Beta Was this translation helpful? Give feedback.
-
It is definitely going through a slow period because Red Hat is stopping Gluster based product. But the project is living on. Some of the maintainers from Red Hat moved to 3 different companies. My company's experiences I talked about with another Maintainer @sanjurakonde at fosdem 2023 last year. https://archive.fosdem.org/2023/schedule/event/sds_lessons_learnt_glusterfs/ Hoping more companies show interest in glusterfs and either hire more developers or buy support from Kadalu in the coming years so that things get better. |
Beta Was this translation helpful? Give feedback.
-
putting my thoughts on this, considering I am one of the maintainers not inside RHT/IBM since at least 5 years. For sure the frequency of jumping on issues and fixing them pro-actively has reduced. But, if there is a PR from any of the other maintainers, then it gets in quicker, as we do watch out all PRs. If there is a new feature, then there should be more discussions to get them in, and may take time. But any CVE/Security or blocker issues would be looked at immediately. One thing which will reduce (and in many cases, has reduced already) is looking at issues, as it takes significant time for each developer, and each of them would be already moved into different companies/projects. This is where, most users would be advised to work with those developers/companies which provide support. |
Beta Was this translation helpful? Give feedback.
-
That's cute but I can list on one hand how many FOSS based SDS stacks that leveraged the GPL but where acquired by a private company and then immediately made proprietary in direct violation of the FSF's GPL. Rules do not matter, when they are not enforced. When is the last time the FSF, copyright or patent holders pushed back against this shady practice? Essentially it's free software development that private companies can exploit with little cost. I completely understand that free doesn't imply cost or monetary gain, only the distribution, as there's no such thing as a fee lunch but it doesn't mean the abuse of FOSS isn't happening at all. Essentially it's the stripping of previous features in favor of support subscriptions based on capacity or the aforementioned previous features but at a price. Providing support services are one thing, but forking from a main branch, privatizing it, removing features and charging money favors the notification of all patent/copyright holders. I farely certain they wouldn't be too happy about their code being straight misused in such a manner. This process is usually a slow burn against FOSS in favor of socialized software but privatized profiteering/closed sourcing it over a certain period of time. In essence companies can claim immunity while simultaneously taking but not actually contributing. Examples: JuiceFS Interesting but dated article related to abusing the "commons clause" for profit. |
Beta Was this translation helpful? Give feedback.
-
There may be many examples where the companies violate the Open Source but I would like to clarify a few things wrt Gluster.
The Gluster source will always be available and the packages/releases will be available based on the release/package maintainers availability. If all the release/package maintainers stop working on Gluster and no releases are available, even then the packages can be built from the source. On other hand, if any company builds the Gluster packages, spends time on testing for real world use cases and assures to provide the updates for the long term, then the interested users may buy the packages from the company. It has nothing to do with the features, people are interested to buy because of the assurance given by the supporting company. Private Gluster packages offerings have been available for a long time from many companies even before Red Hat's decision to make their Gluster product EOL. The point is nobody can make Gluster private. The Open Source project source is always accessible to users.
As per my understanding, all the source code changes must be given back to the main branch as per the license. Please write here if you know any companies violating the license wrt Gluster source.
I wish :) Kadalu Storage is also a Open Source project and it uses the core Gluster components and a new management layer as alternative to Glusterd. Kadalu Storage contributes all the fixes that belong to Gluster core back to the Gluster project. Any changes done to the management layers are only with the Kadalu Storage project since it is not applicable to Gluster (https://github.com/kadalu/moana).
|
Beta Was this translation helpful? Give feedback.
-
Indirectly related to this because the news comes from TrueNas system (after the main news about the completely moving from CORE to SCALE system)…but I want to share with you this, updating the thread. TrueNas SCALE was born to have storage system GlusterFS scaleup system with ZFS backend, but as we can read on the documentation :
...deprecated gluster backend... |
Beta Was this translation helpful? Give feedback.
-
This is just further confirmation and fuel to the fire. Meanwhile, all of the core devs persist with gaslighting the community. |
Beta Was this translation helpful? Give feedback.
-
We are aware of this decision by iXsystems and I responded to the similar queries in the Reddit. In the past, iXsystems sponsored Kadalu Technologies to develop Gluster FS features (https://github.com/gluster/glusterfs/pulls?q=is%3Apr+is%3Aclosed+iXsystems+review%3Aapproved). It is sad to see that the Gluster FS is not fitting there use cases and they are deprecating the Gluster FS integration. Red Hat ending their Gluster based product or some other company deprecating the products will not make the Gluster Open Source project deprecated. I see the community is still active with a few maintainers from multiple companies. Patches are reviewed, maintainers are participating in mailing list, Slack and Github issues. We can't say anything about the future, but I see Gluster community is healthy and still solving many real world use cases.
@anon314159 Why are you so interested in calling the Gluster FS project deprecated? Is this project not responding to your queries or is it missing any features that you needed the most or you are using it in production and worried about the future? |
Beta Was this translation helpful? Give feedback.
-
This has nothing to do with applying false labels to GlusterFS, it's about pragmatism and viability. For additional context my customers and I have a pretty large stake with this SDS project. I have deployed multiple clusters ranging from a few TB's all the way up to 200PB's and have championed this software since 2014. However, there's several very acute yet pervasive issues leading me to believe it's a sinking ship and they are directly related to its stability, usability, and viability. Like everything else in life, there's no such thing as solutions but compromise. I've been using GlusterFS for a decade and determined it to be highly unstable and practically unusable in terms of direct user interaction with the file system. Spurious brick failures when under heavy load and incredibly slow directory traversals when there's a large number of files within them have plagued this project since its inception. For backend purposes GlusterFS is pretty sweet but anything requiring direct user action has been the bane of this project's existence. No product is perfect obviously and there's going to be bugs but some of the pretty severe bugs in this product have persisted for the better part of a decade. Mainly those pertaining to stability and usability. Again, I want GlusterFS to succeed but don't want to place my organization and it's customers at an elevated risk doing so. I intend on using this product for as long as I can even though there's usability issues because of the reed-solomon erasure code implementation and the space efficiency offered by it. Sadly, I really want Gluster to succeed but wanting doesn't make it so in the real world. |
Beta Was this translation helpful? Give feedback.
-
Great points and I agree that Gluster FS has problems and many things to be improved. But all the issues are existing issues, are you saying Gluster FS is not usable after Red Hat doing EOL of their product? We don't gain anything with false advertising. People will only use it if it solves their problem. It is Open Source project, companies sponsor feature development or packages only if they see value in the project and not for false advertisement. Please share if you have better ideas to improve the usability and stability. Or let us know the bugs/issues(Please open the Github issue), I will surely give it a try to fix them (Except big design changes). |
Beta Was this translation helpful? Give feedback.
-
It seems that latest QEMU release has marked as "deprecated" glusterfs backend support! Here is the link: https://wiki.qemu.org/ChangeLog/9.2 |
Beta Was this translation helpful? Give feedback.
-
Description of problem:
The Red Hat Gluster Storage product has a defined support lifecycle through to 31-Dec-24, after which the Red Hat Gluster Storage product will have reached its EOL. Specifically, RHGS 3.5 represents the final supported RHGS series of releases.
GlusterFS was acquired by Red Hat in 2011 so, it's strange that who bought a project, is going to close a product based on that technology.
So, the question is: Is Glusterfs going to be closed or unmaintained in some way?
Beta Was this translation helpful? Give feedback.
All reactions