On Fri, Jun 16, 2017 at 7:23 PM, Alfredo Deza <adeza@xxxxxxxxxx> wrote: > On Fri, Jun 16, 2017 at 2:11 PM, Warren Wang - ISD > <Warren.Wang@xxxxxxxxxxx> 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. Couple of thoughts: - let's keep this in the Ceph repository unless there's a strong reason not to -- it'll enable the tool's branching to automatically happen in line with Ceph's. - I agree with others that a single entrypoint (i.e. executable) will be more manageable than having conspicuously separate tools, but we shouldn't worry too much about making things "plugins" as such -- they can just be distinct code inside one tool, sharing as much or as little as they need. What if we delivered this set of LVM functionality as "ceph-disk lvm ..." commands to minimise the impression that the tooling is changing, even if internally it's all new/distinct code? At the risk of being a bit picky about language, I don't like calling this anything with "volume" in the name, because afaik we've never ever called OSDs or the drives they occupy "volumes", so we're introducing a whole new noun, and a widely used (to mean different things) one at that. John > > >> >> 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-bounces@xxxxxxxxxxxxxx on behalf of adeza@xxxxxxxxxx> 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@xxxxxxxxxxxxxx >> 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 majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
