I don't think to rehearse the list of features of LVM all the time is
a valid argument as we are not even using 10% what LVM is capable of,
and everything we do with it could be done with partitions.
The only thing I see is a new layer that adds complexity to the setup,
a tool that (as Alfredo said, "The amount of internals ceph-volume has
to deal specifically with LVM is enormous") spends most its time
figuring out how things are layered.
I guess I'd be willing to accept LVM a bit more if someone can give me
a single feature of LVM that we desperately need and that nothing else
has.
As of today, I don't think we have demonstrated the value of using LVM
instead of block/partitions because, again, all the races we found
with ceph-disk were ultimately fixed, and they did not apply to
containers!
With the adoption and growth of container, all the logic from the host
with udev rules and systemd is impossible to replicate without
over-engineering our containerized environment.
The simple fact that devices are held by LVM (active) is a nightmare
to work with when running on PVC in the Cloud, and we are seeing a
higher demand for running Rook in the Cloud.
Also, the time we spent on tuning lvm flags for containers is ridiculous.
Device mobility across host is something we had with ceph-disk, and we
lost it with LVM without applying manual commands (to
activate/de-activate VG), and now we need it back when running
portable OSD in the Cloud...
Additionally, we live with too many dependencies on the host (lvm
packages needed, lvm systemd), which sounds a bit silly when running
on k8s since we (in theory) have no possible interaction with the host
configuration.
Sorry, this has turned again into a ceph-disk/ceph-volume discussion...
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Wed, Dec 4, 2019 at 12:13 PM Lars Marowsky-Bree <lmb(a)suse.com> wrote:
On 2019-12-03T19:58:55, Sage Weil <sage(a)newdream.net> wrote:
An LVM-less approach is appealing.
I'm not sure.
LVM provides many management functions - such as being able to
transparently re-map/move data from one device to another, or increasing
LV sizes, say - that otherwise would need to be reimplemented by the OSD
processes.
Something that explicitly does bluestore only and
does not support dmcrypt
could be pretty straightforward, though...
Yes, but given the current deployment ratios, I'd bet this would also
not be applicable to the majority of deployments. Yes, it'd get the very
very simple ones of the ground, but we'd still have to solve the actual
problems. (Plus then maintain the "simple" way on top, and how to go
from there to the more complex one, feature-disparities, DriveGroups for
each, etc etc)
--
SUSE Software Solutions Germany GmbH, MD: Felix Imendörffer, HRB 36809 (AG Nürnberg)
"Architects should open possibilities and not determine everything." (Ueli
Zbinden)
_______________________________________________
Dev mailing list -- dev(a)ceph.io
To unsubscribe send an email to dev-leave(a)ceph.io