On 09/08/18 07:59 +0200, Ulrich Windl wrote: >>>> Ryan Thomas <development...@gmail.com> schrieb am 08.08.2018 um 23:26 in > Nachricht > <CAE_QAjkDx15bR=eb12jcxlx9e0bagex+zjstztwqnougwsk...@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)
pgpy5YICLU0_K.pgp
Description: PGP signature
_______________________________________________ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org