On Wed, 2005-11-16 at 12:14 +0300, Denis Medvedev wrote: > > > > Why not have ssh -like fencing? On a separate channel a ssh command can > be issued to another host to reboot or to just kill cluster processes? > In Linux-HA stonith has a ssh feature. This presumes the host is reachable, and will do the right thing. While the latter may be an acceptable premise, the former is generally not. It will never succeed if the kernel is panicked. There is no limit to how long a live hang can last, so giving up after an arbitrary timeout is a poor idea. The node, then, becomes a single point of failure. Not good, but it is certainly not the worst thing that can happen (e.g. no fencing at all, like the 'null' driver). Certainly, the 'ssh' agent could automatically recover in a few more cases than the 'manual' agent ('meatware' in Linux-HA lingo). > Moreover, why not have a fence_stonith which will invoke stonith as a > fencing agent? Someone mentioned recently (elsewhere) that it would be great if we had a fencing agent which just called some user-specified command to do things (and could substitute variables if necessary, like %p -> password, %l -> login, etc.): i.e. <fencedevice agent="fence_generic" name="foo" exec="/usr/bin/foo"/> ... per-node config: <device name="foo" append="--node node1 --username user --password pass"/> When "node1" needs fencing, fenced would call: /usr/bin/foo --node node1 --username user --password pass" Assuming the above command is guaranteed to reboot node1 (or turn it off), the cluster may safely recover. Maybe this "generic" agent is the right solution after all, and it would fix your second request: you can just call the stonith command if that is what your configuration requires, and that can call the ssh STONITH plugin, right? After all, stonith could call fence_node if someone wrote an external plugin specification for fence_node, too. Well, if it were up to me, I would say "no", but (perhaps...fortunately) it is not up to me. I worry about two things: (a) I do not think this is not a supportable solution, due to the limitless array of possible configurations for hardware we have never heard of. All support for this agent would likely be limited to this mailing list and bugs in the actual agent itself. (b) Rather than developing a proper fence agent for their particular hardware, people will use this as a means to an end, which will not improve the linux-cluster project as a whole. That sucks :( So, given that it is not up to me, who else wants this (I'm talking to you lurkers out there). I am waiting for the flaming mantis to burn me for even suggesting such a thing... -- Lon -- Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster