[pve-devel] DRBD integration but without LINSTOR

[Roland Kammerer]

On Mon, Aug 19, 2024 at 03:37:43PM +0200, sjanssens via pve-devel wrote:
> I am about to complete my internship at Evolix, during which I worked on a
> project to integrate DRBD into Proxmox. This involved manipulating DRBD
> resources and using basic drbd-utils tools. I have now completed the project
> and uploaded it to Gitea. I am wondering if there is any interest in sharing
> this with the community.
> 
> Here are the repository links:
> 
>  * https://gitea.evolix.org/evolix/pve-drbd (new package)
>  * https://gitea.evolix.org/evolix/pve-manager/src/branch/evolix-drbd
>    (fork of pve-manager)
>  * https://gitea.evolix.org/evolix/pve-docs/src/branch/debian (fork of
>    pve-docs)
>  * https://gitea.evolix.org/evolix/pve-storage (fork of pve-storage)
> 
> I am still working on the repositories (particularly to implement
> gitbuildpackage).
> 
> I am including a part of the README below for you to review if you have
> time:

Hi Samuel,

I did read the mail and gave the code a quick look. This is certainly
impressive, but I still fail to answer myself the most basic question:
Why? What did you actually try to solve that has not already been
solved?

>From what you wrote you know that LINSTOR exists. It works, yes, we have
literally LINSTOR clusters with hundreds of nodes and many thousand DRBD
resources. From what I see you re-invented for example some kind of
"cluster management" in SSH.pm where you ssh around nodes. Why would you
do that if you have a cluster aware SDS solution with a REST API?
Obviously you also had to re-invent writing DRBD res files. That is all
functionality that already exists. Let alone all the other features you
get out of LINSTOR/a full SDS for free, including multiple storage
technologies (all of zfs, lvm, thick and thin), LUKS encryption, storage
placement constraints, automatically converting diskless storage to
local storage, consistent(!) snapshots and so on.

So in summary I don't see the benefit of this compared to existing
software that has seen many man-years of development and that is already
used by a substantial customer and FLOSS user base, but I might overlook
something here.

Some other, general thoughts:

Having support for DRBD8 is nice, but we provide dkms packages for DRBD9
publicly and eventually DRBD9 will be upstream (fingers crossed...), so
I don't see a too convincing advantage here.

What certainly is nice is that you seem to have taken care to implement
a more complete GUI workflow (I did not look into that part). Adding a
"storage" ("definition") via the GUI is certainly missing on our end.
Given that it is only like 5 lines in storage.cfg we all lived with it
so far. When I last looked at it this part of PVE was not that plugin
friendly as the storage API. Everything in the direction of abstracting
that would be a benefit for the whole PVE/plugin ecosystem I think.

Best, rck