On 16-6-2017 20:23, Alfredo Deza wrote: > On Fri, Jun 16, 2017 at 2:11 PM, Warren Wang - ISD > <warren.w...@walmart.com> wrote: >> I would prefer that this is something more generic, to possibly support >> other backends one day, like ceph-volume. Creating one tool per backend >> seems silly. >> >> Also, ceph-lvm seems to imply that ceph itself has something to do with lvm, >> which it really doesn’t. This is simply to deal with the underlying disk. If >> there’s resistance to something more generic like ceph-volume, then it >> should at least be called something like ceph-disk-lvm. > > Sage, you had mentioned the need for "composable" tools for this, and > I think that if we go with `ceph-volume` we could allow plugins for > each strategy. We are starting with `lvm` support so that would look > like: `ceph-volume lvm` > > The `lvm` functionality could be implemented as a plugin itself, and > when we start working with supporting regular disks, then `ceph-volume > disk` can come along, etc... > > It would also open the door for anyone to be able to write a plugin to > `ceph-volume` to implement their own logic, while at the same time > re-using most of what we are implementing today: logging, reporting, > systemd support, OSD metadata, etc... > > If we were to separate these into single-purpose tools, all those > would need to be re-done.
Looking at my current work I did on ceph-disk for FreeBSD, it starts to look like something like `ceph-volume zfs`. It would make porting a lot more manageble. But the composable decomposition needs to be at a level high enough that as little as possible of linux-isms seep through. The one that springs to mind in this is: encryption. So +1 --WjW > > >> >> 2 cents from one of the LVM for Ceph users, >> Warren Wang >> Walmart ✻ >> >> On 6/16/17, 10:25 AM, "ceph-users on behalf of Alfredo Deza" >> <ceph-users-boun...@lists.ceph.com on behalf of ad...@redhat.com> wrote: >> >> Hello, >> >> At the last CDM [0] we talked about `ceph-lvm` and the ability to >> deploy OSDs from logical volumes. We have now an initial draft for the >> documentation [1] and would like some feedback. >> >> The important features for this new tool are: >> >> * parting ways with udev (new approach will rely on LVM functionality >> for discovery) >> * compatibility/migration for existing LVM volumes deployed as >> directories >> * dmcache support >> >> By documenting the API and workflows first we are making sure that >> those look fine before starting on actual development. >> >> It would be great to get some feedback, specially if you are currently >> using LVM with ceph (or planning to!). >> >> Please note that the documentation is not complete and is missing >> content on some parts. >> >> [0] http://tracker.ceph.com/projects/ceph/wiki/CDM_06-JUN-2017 >> [1] http://docs.ceph.com/ceph-lvm/ >> _______________________________________________ >> ceph-users mailing list >> ceph-users@lists.ceph.com >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >> >> > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > _______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
