On Mon, 16 Oct 2017, Anthony Verevkin wrote: > > > From: "Sage Weil" <sage@xxxxxxxxxxxx> > > To: "Alfredo Deza" <adeza@xxxxxxxxxx> > > Cc: "ceph-devel" <ceph-devel@xxxxxxxxxxxxxxx>, ceph-users@xxxxxxxxxxxxxx > > Sent: Monday, October 9, 2017 11:09:29 AM > > Subject: killing ceph-disk [was Re: ceph-volume: migration and disk partition support] > > > > To put this in context, the goal here is to kill ceph-disk in mimic. > > > > > > Perhaps the "out" here is to support a "dir" option where the user > > can > > manually provision and mount an OSD on /var/lib/ceph/osd/*, with > > 'journal' > > or 'block' symlinks, and ceph-volume will do the last bits that > > initialize > > the filestore or bluestore OSD from there. Then if someone has a > > scenario > > that isn't captured by LVM (or whatever else we support) they can > > always > > do it manually? > > > > In fact, now that bluestore only requires a few small files and symlinks > to remain in /var/lib/ceph/osd/* without the extra requirements for > xattrs support and xfs, why not simply leave those folders on OS root > filesystem and only point symlinks to bluestore block and db devices? > That would simplify the osd deployment so much - and the symlinks can > then point to /dev/disk/by-uuid or by-path or lvm path or whatever. The > only downside for this approach that I see is that disks themselves > would no longer be transferable between the hosts as those few files > that describe the OSD are no longer on the disk itself. :) this is exactly what we're doing, actually: https://github.com/ceph/ceph/pull/18256 We plan to backport this to luminous, hopefully in time for the next point release. dm-crypt is still slightly annoying to set up, but it will still be much easier. sage _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |