From: vitalif@yourcmc.ru
To: "Thomas Lamprecht" <t.lamprecht@proxmox.com>,
"Proxmox VE development discussion" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] Vitastor block driver plugin
Date: Wed, 27 Aug 2025 22:58:20 +0000 [thread overview]
Message-ID: <caf682bffe120682289aa5a5ba0fb1a1@yourcmc.ru> (raw)
In-Reply-To: <1ff9fa45-752d-4935-a8b7-993096413749@proxmox.com>
Hi Thomas,
Thanks for your answer!
Regarding the "bus factor", I totally understand your concerns, but I guess it's more about popularity than about the number of developers. I mean if you take a startup with 10-20 devs it may run out of investor money and become abandoned as well as if there is only 1 developer. And I'd of course appreciate more popularity and if more people joined my project :) but after all, opensource is about indie developers too, not only about companies? So I don't think it should be a blocker. Vitastor has users, some of them use Proxmox by the way, there's also a partner company in Russia which offers commercial support for it.
C++ can be different :) the C++ I use is more like "C with classes" than modern idiomatic C++... I try to avoid complex features of the language as well as complex external libraries.
So yeah, try to evaluate it when you have spare time :) it's like 10x faster in terms of latency, has very similar tooling to ceph and PVE seems to be very easy to use Vitastor with. Also you're the only system which doesn't have hardcode and thus doesn't require patching core to install a 3rdparty block driver! It's really cool. OpenNebula, OpenStack, oVirt all require patches, both to their core and to libvirt. I really appreciate your libvirt-free approach. :)
I thought about upstreaming the QEMU driver, but then the first thing that I have to solve is getting my client library packaged in at least one of distros used in their CI: alpine, ubuntu, debian, fedora, centos or opensuse. Then they can consider accepting the driver. It seems I have to try to do it, at least at some point. :)
So to sum it up, at the moment it's perfectly fine for me if you just add that 1 line with vitastor options in that list. :-)
By the way, why did you add it in the first place? I thought these options could only contain "trusted" values coming from PVE code anyway? Or do some drivers really require filtering?
--
With best regards,
Vitaliy Filippov
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
prev parent reply other threads:[~2025-08-27 22:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 14:33 vitalif
2025-08-27 9:13 ` Thomas Lamprecht
2025-09-01 9:42 ` Fiona Ebner
2025-08-27 22:58 ` vitalif [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=caf682bffe120682289aa5a5ba0fb1a1@yourcmc.ru \
--to=vitalif@yourcmc.ru \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox