On Fri, 2 Dec 2016, Lars Marowsky-Bree wrote: > On 2016-12-01T00:15:25, John Spray <jspray@xxxxxxxxxx> wrote: > > > Put another way, I'd like it to be the case that people who want to > > twiddle LEDs can write a ceph-mgr module that does that, rather than > > having to push out a libstoragemgmt-enabled agent to the Ceph servers. > > I'm not sure I agree. > > I understand some of the motivation, but the key use cases where I'd > want to "twiddle LEDs" involve enclosures that either don't yet have an > OSD deployed (e.g., where to plug in the new disk), or where the OSD has > failed (and may not even be able to start). > > And I don't want to have to maintain multiple paths for interacting with > the enclosures. I agree with John that it would be great to have ceph-mgr plugins doing this sort of thing. But the OSD can't be the only path, and I also don't like the idea of multiple paths. The problem is that there needs to be something on the hosts that's doing this, and I don't want to just ignore it and hope some other layer solves it; years have gone by and nobody has done it, and I'd like to avoid a fragmented approach if we can. On the other hand, if we simply make an opinionated choice about some other per-host agent service, like we did in the original Calamari (which used salt and zeromq, IIRC), we'll probably end up offending more users than we please. Perhaps the way forward is to pick *some* external host agent and service to start with and ensure that it is integrated into ceph-mgr in a pluggable way such that we have (1) the osd:device mappings available, (2) a standard API for working with LEDs etc, and (3) a working plugin for twiddling the LEDs, but ensure that other "disk services" backends can also be used? sage -- 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
