>>> Klaus Wenninger <[email protected]> schrieb am 17.03.2022 um 18:03 in Nachricht <CALrDAo19DnqgRfvn4HFAP9y1W2__FTzySnh_MK_+W3wfo=+q...@mail.gmail.com>: > On Thu, Mar 17, 2022 at 4:16 PM Ulrich Windl < > [email protected]> wrote: > >> Hi! >> >> I had the idea to display the status of a cluster node on the 14-character >> LCD display of a Dell PowerEdge server; preferably displaying the hostname >> at least partially, too ;-) >> >> Now, what would you display, and how would you display it? >> >> (Actually I already have something (e.g. "h18:T[3Q_]P8V"), but I'd like to >> get your ideas) >> > > hmm ... that isn't even enough for a bit.ly-link ;-) > > >> >> BTW, I also wanted to write a pseudo fencing agent that displays >> "Fencing..." on the LCD when the node is being fenced (hopefully it will >> stay there during reboot), but I realized that the documentation is rather >> incomplete. Most of all I don't really have a fencing-test environment... >> > > Something like > https://github.com/ClusterLabs/fence-agents/blob/main/agents/heuristics_ping > /fence_heuristics_ping.py > to be used with a fencing-topology? > With a simple client on the node to be fenced and always returning success > ... > Unfortunately it probably won't work in most of the interesting cases as > either the to > be fenced node isn't gonna be alive enough or connectivity is gone. > Or is it possible to make the remote-management (aka fencing-device) talk > to the > display somehow to display a configurable text. > Going with an alert agent or registering for fence-history (history would > be reported > on all nodes - thus no need for additional communication) probably isn't > gonna be > helpful either as I think you can't see partial success on a topology - > just when it > is reported to be finally killed - well to late then to do something on the > node to be killed :-(
(for the pseudo-fencing agent) The idea was that the fencing agent would operate locally on the node to be fenced (would probably work only if the fencing reason was a stop failure). As an action the agent would just set a message to the display and then report a fencing failure, so that the next (real this time) agent would fence the node eventually. You are right: That requires a fencing topology. Regards, Ulrich _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
