[ceph-users] killing ceph-disk [was Re: ceph-volume: migration and disk partition support]
chibi at gol.com
Mon Oct 16 16:25:32 PDT 2017
On Mon, 16 Oct 2017 18:32:06 -0400 (EDT) Anthony Verevkin wrote:
> > From: "Sage Weil" <sage at newdream.net>
> > To: "Alfredo Deza" <adeza at redhat.com>
> > Cc: "ceph-devel" <ceph-devel at vger.kernel.org>, ceph-users at lists.ceph.com
> > Sent: Monday, October 9, 2017 11:09:29 AM
> > Subject: [ceph-users] 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.
If the OS is on a RAID1 the chances of things being lost entirely is
reduced very much, so moving OSDs to another host becomes a trivial
exercise one would assume.
But yeah, this sounds fine to me, as it's extremely flexible.
Christian Balzer Network/Systems Engineer
chibi at gol.com Rakuten Communications
More information about the ceph-users