From: "Piotr Dałek" <branch@predictor.org.pl>
To: John Spray <jspray@redhat.com>
Cc: Joao Eduardo Luis <joao@suse.de>, Sage Weil <sweil@redhat.com>,
Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: disk enclosure LEDs
Date: Thu, 1 Dec 2016 09:35:56 +0100 [thread overview]
Message-ID: <20161201083556.GO26997@predictor> (raw)
In-Reply-To: <CALe9h7d3Lv5Hwxh0sdtkSXQrPZqXG2UdVc2nvSN9ra2Gu6eM5A@mail.gmail.com>
On Thu, Dec 01, 2016 at 12:15:25AM +0000, John Spray wrote:
> On Wed, Nov 30, 2016 at 7:37 PM, Joao Eduardo Luis <joao@suse.de> 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.
Major server vendors already provide tools to play with drive and/or server
LEDs and many users of these machines already make use of these tools in
their own setups. Combining them with Ceph would be confusing if both these
tools and Ceph will try to manage lights.
On the other hand, I don't believe that libstoragemgmt is reliable enough to
cover enough users without bringing influx of Ceph bugs/issues that are
really a libstoragemgmt faults due to incompatibilities/bugs/lack of support.
--
Piotr Dałek
branch@predictor.org.pl
http://blog.predictor.org.pl
next prev parent reply other threads:[~2016-12-01 8:33 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-30 16:51 disk enclosure LEDs Sage Weil
2016-11-30 18:57 ` Brett Niver
2016-11-30 19:37 ` Joao Eduardo Luis
2016-12-01 0:15 ` John Spray
2016-12-01 1:46 ` Allen Samuels
2016-12-01 8:35 ` Piotr Dałek [this message]
2016-12-01 13:02 ` Joao Eduardo Luis
2016-12-02 9:23 ` Lars Marowsky-Bree
2016-12-02 14:23 ` Sage Weil
2016-12-02 14:27 ` Lars Marowsky-Bree
2016-12-02 15:27 ` Bassam Tabbara
2016-12-02 16:57 ` Allen Samuels
2016-12-02 17:17 ` Lars Marowsky-Bree
2016-12-02 17:57 ` Alan Johnson
2016-12-02 18:05 ` Allen Samuels
2016-12-05 12:44 ` John Spray
2016-12-05 12:58 ` Lars Marowsky-Bree
2016-12-05 13:23 ` Jeff Applewhite
2016-12-05 15:28 ` John Spray
2016-12-05 17:48 ` Bassam Tabbara
2016-12-05 18:02 ` Allen Samuels
2016-12-05 18:41 ` Lars Marowsky-Bree
2016-12-05 19:28 ` John Spray
2016-12-05 22:50 ` Allen Samuels
2016-12-06 0:20 ` John Spray
2016-12-06 2:18 ` Allen Samuels
2016-12-02 18:24 ` Sage Weil
2016-12-01 0:10 ` John Spray
2016-12-01 13:19 ` Lenz Grimmer
2016-12-01 15:27 ` Jesse Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161201083556.GO26997@predictor \
--to=branch@predictor.org.pl \
--cc=ceph-devel@vger.kernel.org \
--cc=joao@suse.de \
--cc=jspray@redhat.com \
--cc=sweil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.