On Apr 21, 2015, at 9:58 AM, Gregory Meno <gmeno@xxxxxxxxxx> wrote: cross posting to ceph-calamari@xxxxxxxxxxxxxx in case we have interest there too. > On Apr 1, 2015, at 2:52 PM, Handzik, Joe <joseph.t.handzik@xxxxxx> wrote: > > Hey all, > > Gregory Meno’s pull request in Calamari (https://github.com/ceph/calamari/pull/267) is motivating some discussion about a feature (or set of features) that I’m about to start working on. > > My goal is to allow users to enable the identify and fault LEDs (fault is negotiable) via the Calamari GUI. I’ve had some discussion with Dan Mick and Gregory Meno about the concept, and they both see the value in it. The decision that needs to be made is…where should this functionality exist? There are a couple of obvious choices, after Gregory’s SMART patch: > > 1. Stick everything in Calamari via Salt calls similar to what Gregory is showing. I have concerns about this, I think I’d still need extra information from the OSDs themselves. I might need to implement the first half of option #2 anyway. > 2. Scatter it across the codebases (would probably require changes in Ceph, Calamari, and Calamari-clients). Expose the storage target data via the OSDs, and move that information upward via the RESTful API. Then, expose another RESTful API behavior that allows a user to change the LED state. Implementing as much as possible in the Ceph codebase itself has an added benefit (as far as I see it, at least) if someone ever decides that the fault LED should be toggled on based on the state of the OSD or backing storage device. It should be easier for Ceph to hook into that kind of functionality if Calamari doesn’t need to be involved. > > Dan mentioned something I thought about too…not EVERY OSD’s backing storage is going to be able to use this (Kinetic drives, NVDIMMs, M.2, etc etc), I’d need to implement some way to filter devices and communicate via the Calamari GUI that the device doesn’t have an LED to toggle or doesn’t understand SCSI Enclosure Services (I’m targeting industry standard HBAs first, and I’ll deal with RAID controllers like Smart Array later). > > I’m trying to get this out there early so anyone with particularly strong implementation opinions can give feedback. Any advice would be appreciated! I’m still new to the Ceph source base, and probably understand Calamari and Calamari-clients better than Ceph proper at the moment. > > Thanks, > > Joe Joe, I’ve been thinking about how to expose this new hardware context in the calamari API. I propose we add an end point like /api/v2/hardware and each entry there is something that relates to ceph in that we know what ceph subsystem is affected by the hardware entry being in a particular state e.g. OK, WARN, FAIL. This state is a result of the checks like SMART. This /hardware endpoint would be a collection of all hardware that we can have checks for or the OSD advertises that it rely on. This endpoint is good for an overview for someone who wants a current status of hardware independent of cluster context. Naturally I expect this info to be present in context within /api/v2/cluster/FSID/osd/N and other endpoints describing Ceph primitives. That helps UIs have better context without having to do the correlation in the client. It seems like it would be helpful to have the OSDs report their underlying data storage target. How would you expose the backing storage for the OSD? Is it a command line query, configuration, part of the OSD map, or something else? regards, Gregory -- 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
