Currently, Rook does not create partitions and this is my last resort option. Thanks! ––––––––– Sébastien Han Senior Principal Software Engineer, Storage Architect "Always give 100%. Unless you're giving blood." On Thu, Dec 5, 2019 at 12:35 PM Alfredo Deza <adeza@xxxxxxxxxx> wrote: > > 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
