On Thu, Dec 5, 2019 at 4:34 AM Sebastien Han <shan@xxxxxxxxxx> wrote: > > 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! I would still be interested to see how (why) partitions created by rook and then populated in /etc/ceph/osd/<id>.json does not work for the purposes you've stated. It doesn't tie you to LVM which seems problematic for you, and still allows you to do all the OSD variations including dmcrypt. > > 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@xxxxxxxx> wrote: > > > > On 2019-12-03T19:58:55, Sage Weil <sage@xxxxxxxxxxxx> 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@xxxxxxx > > To unsubscribe send an email to dev-leave@xxxxxxx > > > _______________________________________________ > Dev mailing list -- dev@xxxxxxx > To unsubscribe send an email to dev-leave@xxxxxxx _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
