> -----Original Message----- > From: ceph-devel-owner@xxxxxxxxxxxxxxx [mailto:ceph-devel- > owner@xxxxxxxxxxxxxxx] On Behalf Of John Spray > Sent: Wednesday, November 30, 2016 4:15 PM > To: Joao Eduardo Luis <joao@xxxxxxx> > Cc: Sage Weil <sweil@xxxxxxxxxx>; Ceph Development <ceph- > devel@xxxxxxxxxxxxxxx> > Subject: Re: disk enclosure LEDs > > On Wed, Nov 30, 2016 at 7:37 PM, Joao Eduardo Luis <joao@xxxxxxx> wrote: > > On 11/30/2016 04:51 PM, Sage Weil wrote: > >> > >> Since this is in a reasonably usable state, I think It's time for us > >> to figure out how we are going to do this in ceph. > >> > >> A few ideas: > >> > >> ceph osd identify osd.123 # blink for a few seconds? > >> > >> or > >> > >> ceph osd ident-led-on osd.123 # turn on ceph osd ident-led-off > >> osd.123 # turn off ceph osd fault-led-on osd.123 # turn on ceph > >> osd fault-led-off osd.123 # turn off > >> > >> This would mean persistently recording the LED state in the OSDMap. > >> And it would mean ceph-osd is the one twiddling the LEDs. But that > >> might not be the way to go in all cases. For example, if we have an > >> OSD that fails, once we confirm that we've healed (and don't need > >> that OSDs data) we'd probably want to set the fault light so that the > >> disk can be pulled safely. In that case, ceph-osd isn't running > >> (it's long-since failed), and we'd need some other agent on the node > >> to twiddle the light. Do we really want multiple things twiddling lights? > > > > > > Although this is really neat, I don't think ceph is the place to > > implement or even manage it. > > > > This should fall under a management tool's purview. > > I would agree that any persistence/policy parts don't belong in the OSD or > the mons, but the remote access part where we reach across the network > and do something with libstoragemgmt is very useful to have inside Ceph, > because it means we can have management tools that just speak librados > and don't have to have their own remote access to all the nodes in the > system. > > 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. +100 > > John > > > That doesn't mean we couldn't keep some info on ceph itself, but in > > that case it should be kept either on the mon's kv config-key or > > ceph-mgr (e.g., set of osds that actually support this, which led to > > turn if something misbehaves, whatever). > > > > And adding this sort of information to the osdmap is overkill. This is > > not something that the osds should be concerned about, but whatever > > tool/service monitors the osds. > > > > Besides, we'd be taking a stand on how to do something completely ceph > > unrelated - "how to blink your enclosure's leds". I'm guessing this > > will be hardware dependent; availability of the required libraries > > will be distro dependent; and people may want to implement this in > > totally different ways from whatever we concoct here. > > > > I don't see a good argument to delegate this to ceph. > > > > -Joao > > > > -- > > 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 ��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
