[Pacemaker] Full API description for Fence Agent

[Andrew Beekhof]

On 15/06/2013, at 12:25 AM, Lars Marowsky-Bree <lmb at suse.com> wrote:

> On 2013-06-14T10:50:21, Andrew Beekhof <andrew at beekhof.net> wrote:
> 
>> If I had my way, they'd
>> - have env variables the same as OCF
>> - be executable from the command line like the RH ones
> 
> (I'm not sure I get the second point. Even the "old" cluster-glue
> scripts were executable from the commandline?)

The RH ones are executable directly, not relying on separate command line utils.

> 
>> - avoid the 350 layers of indirection in the glue ones (C plugins forking bash scripts and "here's the list of hosts so that I can ask you the list of hosts" stuff)
> 
> Yeah, the cluster-glue ones started out from a quite different premise.
> Originally, since they were considered part of the write-out recovery
> path, they were supposed to be pre-loaded into mlock'ed memory. (It's a
> neat idea, it's just that noone does bothered to write those.)
> 
> Over the years, that has eroded more and more; nowadays, a lot of that
> stuff no longer makes any sense.

Yep. I know why things work that way, but reality got in the way :)

> 
> And for fencing mechanims that are not self-aware (like querying
> switches about the ports they can fence), that indirection really
> doesn't make sense and the fence supervisor should directly parse the
> hostname/hostlist.
> 
> Hence, my question as to merging, because I really would like to get rid
> of supporting both ;-)
> 
>> - provide a common shell and/or python library for option handling
>> (env -> $x, stdin -> $x, command line options -> $x)
>> 
>> IMHO the RH ones are the closest to ideal and almost all use a common
>> python library so adding environment variable support would only have
>> to happen once (using the same names as for stdin).
> 
> Yes, I think the RH APIs might be better. I'm planning on adding a
> fence_sbd wrapper for example, and wondering how much code pacemaker
> could save if the cluster-glue ones were dropped?

Code in Pacemaker?  Not much, just fence_legacy I think.

> (I'm assuming that fence-agents has most devices too; or that the agents
> could be changed to conform with that interface.)

I think most devices are covered.  Here is the install list (there may be more that we don't ship):

fence-agents-ipmilan-4.0.0-5.el7.x86_64
fence-agents-drac5-4.0.0-5.el7.x86_64
fence-agents-wti-4.0.0-5.el7.x86_64
fence-agents-ifmib-4.0.0-5.el7.x86_64
fence-agents-intelmodular-4.0.0-5.el7.x86_64
fence-agents-vmware-soap-4.0.0-5.el7.x86_64
fence-agents-cisco-ucs-4.0.0-5.el7.x86_64
fence-agents-eaton-snmp-4.0.0-5.el7.x86_64
fence-agents-eps-4.0.0-5.el7.x86_64
fence-agents-apc-4.0.0-5.el7.x86_64
fence-agents-bladecenter-4.0.0-5.el7.x86_64
fence-agents-ipdu-4.0.0-5.el7.x86_64
fence-agents-ilo2-4.0.0-5.el7.x86_64
fence-agents-rsb-4.0.0-5.el7.x86_64
fence-agents-ilo-mp-4.0.0-5.el7.x86_64
fence-agents-apc-snmp-4.0.0-5.el7.x86_64
fence-agents-common-4.0.0-5.el7.x86_64
fence-agents-rhevm-4.0.0-5.el7.x86_64
fence-agents-hpblade-4.0.0-5.el7.x86_64
fence-agents-cisco-mds-4.0.0-5.el7.x86_64
fence-agents-ibmblade-4.0.0-5.el7.x86_64
fence-agents-kdump-4.0.0-5.el7.x86_64
fence-agents-scsi-4.0.0-5.el7.x86_64