Glusterfs is still maintained. Please don't drop support!

[alpha754293]

the Gluster plugin WORKED in previous versions. to ensure that it CONTINUES to work is a non trivial investment in manpower and development time

Line 32 of debian/control just calls for the glusterfs-client.

PVE isn't responsible for maintaining said glusterfs-client package which is the core package that enables gluster to work in/with PVE.

lines 674 and 753 of pve.sm calls for the Glusterfsplugin.pm which was deleted in the 16 Jun 2025 commit (commit id# 7669a99e97f3fd35cca95d1d1ab8a377f593dccb) (so a little less than a year ago, as of this writing), deleted a plugin that a) already exists and b) already works.

Again, PVE isn't responsible for maintain the glusterfs-client that this all rides on.

And since a lot of people have already said that there isn't much activity going on with glusterfs anyways (activity is slow, but not nothing), therefore; the chances that something breaks with an existing glusterfs-client package would usually/generally be quite low, especially if it is stable and has been working for some time.

It be one thing if they're dropping the glusterfs-client package because it doesn't work but that's not the case here.

What makes you think that PVE is responsible for making sure that glusterfs-client isn't broken?

If it was broken and PVE decides to drop it, at least that's understandable.

The PVE team dropping this for a part of QEMU that PVE doesn't even use - that's just silliness.

Is the glusterfs-client package broken? No?

Does PVE use QEMU's native glusterfs client? No?

Then the stated reason for dropping it doesn't apply.

IIRC, I think that someone else here has said that the user is free to use the glusterfs-client as a directory mount point, which is what the plugin does for you.

They made the decision to drop the commitment to supporting gluster in order to commit their resources to other aspects of the stack they deem is of more importance.

No, that's not the stated reason for dropping gluster.

This is what @Thomas Lamprecht wrote, for this commit (as the "official" stated reason for dropping gluster);

drop support for using GlusterFS directly

As the GlusterFS project is unmaintained since a while and other
projects like QEMU also drop support for using it natively.

One can still use the gluster tools to mount an instance manually and
then use it as directory storage; the better (long term) option will
be to replace the storage server with something maintained though, as
PVE 8 will be supported until the middle of 2026 users have some time
before they need to decide what way they will go.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

The part about gluster not being maintained simply isn't true.

(Again, @alexskysilk you wrote what you wrote on the assumption that it is up to the PVE devs to make sure that the glusterfs-client package still works (because that's what pvesm.pm and Glusterfsplugin depends on.)

If it still works, then there's no reason to remove it.

The reason that Thomas gave for removing it is partially false (re: that it isn't maintained). PVE doesn't use the QEMU native support, and therefore; Thomas' second reason is irrelevant.

GlusterfsPlugin.pm already exists and as long as glusterfs-client package works, then there is little reason to think that said GlusterfsPlugin.pm won't work.

If it ain't broke, why break it?

(PVE doesn't use QEMU's native glusterfs client/support/backend and gluster is still maintained, even if (very) slowly. You can look at the PRs that were merged. Again, if a code is stable enough, wouldn't you expect the number of commits per month to decrease?)

So simple.

 

[alexskysilk]

You asked for an answer, and you received one. litigating your point of view is not relevant, interesting, or consequential. You dont have to ACCEPT the answer. You choices remain the same as before the wall of text (which I didnt read, apologies.)

 

[alpha754293]

You asked for an answer, and you received one.....You don't have to ACCEPT the answer.

The answer that was provided is riddled with inaccuracies and/or statements that are just patently and/or knowingly fraudulent misrepresentations that went into said answer.

It'd be one thing if the answer was even remotely factually accurate, but alas, sadly, it is not (as shown above).

It'd be one thing to give people bad information because the person giving said advice doesn't know.

But to knowingly give out wrong information, I would have to imagine that's worse, right?

PVE isn't responsible for maintaining the glusterfs-client Debian package that the GlusterfsPlugin.pm (and debian/control and pvesm.pm) depends on. They just have to rollback the commits which deleted those lines and like I said, people who don't use it wouldn't even notice and it brings back a feature/functionality that wasn't even broken.

Again, if/when the glusterfs-client breaks and PVE decides to remove it because it broke and therefore; is no longer useful/valid - then sure. I agree with that (reasoning/rationale).

But to take it out because of a part of QEMU that PVE doesn't even use - that's just silly.

PVE devs can leave the GlusterfsPlugin.pm in its last known good state and don't even have to touch it. If/when it breaks, they can take it out in the future. But if it isn't broken now, then why take it out based on something that PVE doesn't even use from QEMU? That's just silly.