Some questions and comments:
- What is the user interaction? Is he specifying an OSD ID for which
he wants to blink the light or what is $PATH? If $PATH is a device
name such as /dev/sdb we would need to translate the OSD ID to the
device.
- This feels like a "desired state" way of doing things since you want
a light on until you decide to turn it off. In this case, we could
create a CRD for desired state of device lights. CRDs are the way the
rook module should interact with the rook operator.
- Whenever the CRD changes, rook would update the lights. When
rook starts, it would also ensure the lights are set appropriately.
- If a CRD is created it could mean the light should turn on for
that device. If the CRD is deleted, the light should turn off. If
there were different blinking modes, there could be a setting in the
CRD to indicate such.
- What does it take to detect the current state of the lights? Do we
run lsmcli on each node? If so, the discovery daemonset would make
sense to do this.
If we didn't use a CRD, the rook module could store the settings in a
configmap, then run a k8s job itself to turn the lights on or off.
However, I'd say the CRDs are the more natural approach.
Travis
On Wed, Feb 27, 2019 at 3:25 PM Gregory Farnum <gfarnum@xxxxxxxxxx> wrote:
>
> On Wed, Feb 27, 2019 at 1:16 PM Sage Weil <sweil@xxxxxxxxxx> wrote:
> >
> > See
> >
> > https://github.com/ceph/ceph/pull/26684
> > https://pad.ceph.com/p/blinky-lights
> >
> > I think the hurdles are:
> >
> > - Add the appropriate hook to orchestrator_cli to turn a light on or off.
> > Right now the code to remote() to the orchestrator is commented out in my
> > PR. The call sites have the device id (vendor/model/serial), host, and
> > device name (e.g., sda).
> >
> > - Get a recentish libstoragemgmt into the rook container image, or some
> > other container image we can schedule.
> >
> > - Either teach rook how to do a one-off "run this command on this host" to
> > turn a light on or off, or teach the mgr rook module to schedule that
> > command itself. I'm not sure whether or not we want/need rook in the loop
> > for turning these lights on or not... thoughts? It seems like if rook
> > does it, it needs a configmap (or something) to store the state of lights
> > it wants on or off so it can reset them when it restarts. The mgr module
> > can (should?) do the exact same thing when the mgr restarts.
>
> This sounds like you need an interface for querying the state of
> lights as well then? I presume the dashboard wants to show what lights
> are on or off, not merely let admins push a button to change them...
>
> >
> > For the record, the lsmcli command we ultimately need to run is
> >
> > lsmcli local-disk-fault-led-on --path $PATH
> >
> > modulo s/fault/ident/ or s/on/off/.
> >
> > sage
> >
