[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: [Linux-cluster] Fencing Driver API Requirements

I agree also,

but my problem is much more basic: to my mind this whole cluster is so badly documented, that it's
really hard to believe we have talked for years about how linux can be business-critical platform...

>From a normal human being like myself it has taken incredible reverse-engineering just to find all pieces
of information, one piece here and one there and nothing from RH, to just understand how cluster works. 

Versions go on, things change and information just gets old just when I understand it.

Just an example: When I first used qdisk I leared that I have to tune deadnode_timeout. When moved to ver5
 /proc/cluster got lost... so had to figure out.... ahaa its totem token now... RH support didn' know
this. This kind of frustrating things happen to me all the time.

Information is splitted to man- pages, wiki, faq's, poor RH- manuals, different txt- files from the
deepnes of internet. I have had to use all my poor genetic power to trie to create theorys about this
cluster as an administrator.


-----Original Message-----
From: linux-cluster-bounces redhat com on behalf of Marek 'marx' Grac
Sent: Tue 4/22/2008 18:09
To: linux clustering
Subject: Re: [Linux-cluster] Fencing Driver API Requirements

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 redhat com


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]