[ClusterLabs] How to implement a fencing agent

[Jan Pokorný]

On 09/08/18 07:59 +0200, Ulrich Windl wrote:
>>>> Ryan Thomas <developmentrjt at gmail.com> schrieb am 08.08.2018 um 23:26 in
> Nachricht
> <CAE_QAjkDx15bR=eb12jCxLX9e0BaGex+zjsTztWQnOugwsKK3w at mail.gmail.com>:
>> I’m attempting to implement a fencing agent.
>> 
>> The ClusterLabs/fence-agent github repo has some helpful information
>> including fence-agents/doc/FenceAgentAPI.md, but I haven’t found the
>> answers to a few basic questions.
> 
> Personally I think a specification should not recommend any library to use,
> but state in simple and precise words what the thing (=fencing agent)
> is expected to do.

+1 for a complete decoupling of API specification and referential
library, it's pretty possible there are still some undocumented bits
relied upon while only hardwired into the fencing library.  Note that
pacemaker adds a thin configuration surface and decision logic on top
of the base line set forth in the mentioned document.

Also, mentioning Python below, there are certainly reasons why it can
be more blessed than say shell scripting, though I stay vocal that
transition from compiled fence agents was rather a regress than
progress (not to speak about original Linux HA project going as far as
to have ready-to-use agents preloaded in memory to achieve
unprecedented robustness -- please correct me if I get these gory
details about the past wrong).

The problem with Python is that even for a trivial proxying of the
operations towards 3rd party tooling (e.g. ipmitool), the costs of
bringing the run-time up alone is unexpectedly I/O intensive (trying
to open plethora files, preinitializing some objects that won't be
used, anyway, etc.), with excessive complexity of the task/memory
footprint proportion, and currently also carrying a risk of being
affected/delayed with user customization of the Python deployment
that gets loaded automatically unless suppressed [1].  That's not
very aligned with the goal of preventing dangerous access to shared
resources in timely and reliable fashion.

Perhaps a reasonable tradeoff at this point would be to consider
MicroPython, alternative lightweight implementation with a trimmed
standard library: https://micropython.org/.  As a first step, fencing
library would likely require some touches for compatibility, though.

> Inspecting the source of SBD I found out that there is too much
> undocumented magic implemented.

>> 1. The documentation encourages the use of the python fencing library.  
>>    How does one install this?

Fencing library is basically this file (sans the doubled extension):
https://github.com/ClusterLabs/fence-agents/blob/v4.2.1/lib/fencing.py.py
that shall be assurably in predefined/run-time-mangled
search path for Python modules (sys.path), so that you can then
"from fencing import ...".  You can follow the native agents for
how it is to be used.

For instance, EL family of distros will provide that file as
/usr/share/fence/fencing.py by the means of fence-agents-common
package.

>> 2. How to a “register” the agent so it shows up in the “pcs stonith
>>    list” output, and the “stonith_admin –list-installed” output? 
>>    So, I can use my new agent?

Living convention for this is that whatever in /usr/sbin
(symbolically in pacemaker context: RH_STONITH_DIR) named in way
that conforms "fence_*" glob pattern (symbolically RH_STONITH_PREFIX)
will qualify automatically.  Obviously, it shall be marked executable.


Hope this helps.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1600893

-- 
Nazdar,
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20180809/2850ad2d/attachment-0002.sig>