Hi,
Jonathan Buzzard wrote:
On Mon, 2008-04-14 at 20:47 +0200, Marek 'marx' Grac wrote:
The issue is that with such a critical component of a cluster (if the
fencing is not right bad things will happen) that in order to write a
new fencing agent one has to start reverse engineering from source to
work out what you need to do.
Those new agents with python module are available only in developer
branch are not a part of any distribution yet. There will be a
documentation soon. Supported fencing agents has their man pages are
there is description of how they work as they can use both getopt and
stdin arguments. These options does not have to have anything common, as
they are taken from the cluster.conf. Unfortunately some of the existing
fencing agents use different options, so there are no standard options
[there is an attempt to have them in new fencing agents].
This is incredibly bad practice, and is bound to lead to improperly
implemented fencing agents that then lead to bad things happening on
clusters with these fencing agents.
I agree.
There a loads of potential fencing devices out there that could be
supported, that are currently not. From my perspective trying to
implement a fencing agent for Alert On Lan 2, it was easier to reverse
engineer the magic packets of death using tcpdump and IDA pro as well as
implementing a C based Linux command tool to generate them, than it has
been to write a functioning fencing agent.
It would take a couple of hours tops for someone to write a spec for
what a fencing agent needs to do.
--
Marek Grac
Red Hat Czech s.r.o.
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
