[ClusterLabs] Antw: [EXT] Re: Request for ideas: Cluster node summary in 14 characters

[Ulrich Windl]

>>> Klaus Wenninger <kwenning at redhat.com> schrieb am 17.03.2022 um 18:03 in
Nachricht
<CALrDAo19DnqgRfvn4HFAP9y1W2__FTzySnh_MK_+W3wfo=+Qew at mail.gmail.com>:
> On Thu, Mar 17, 2022 at 4:16 PM Ulrich Windl <
> Ulrich.Windl at rz.uni-regensburg.de> 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