Hi Linux-HA Users!

Heartbeat and Pacemaker make use of shellscripts for the definition of OCF 
resource agents.
This approach was very good since it has lead to a wide distribution of 
Pacemaker on various platforms since
shell scripts are quite portable.

On the other hand
* the debugging of shellscripts is a pain.
* also to my knowledge there are no facilities to do TDD development of shell 
script resource agents.
* another point is that shell scripts do not have inheritance. So every OCf 
agent is unique. It is quite a task in shell script
    to capsulate busines logic that is common and make it a basis for other 
resource agent scripts.

As an ISP we have lots of services that needs HA. We used Heartbeat/pacemaker 
for more years we are counting.
We have written resource agents and modified some we find on the wild to fit 
our needs. But in the end we came up with a mess of
ugly, not well documented, and untested shell code that we have to maintain for 
ages.

Since most of our hosting is python related we decided at some time to write 
python based resource agents. But also we ended up
in a mess of ugly, untested script code.

Recently we invested quite a bit of time to write a nice piece of code the 
inqus.ocf framework.
It consists of two python packages
*  inqbus.ocf.generic
        which brings the basic classes and data structures and some magic - huh.
* inqbus.ocf.agents
       which brings
            pidBaseAgent:
                a very advanced base class for dealing with posix and PID based 
daemon processes.
            pidAgent:
               a heir of pidBaseAgent which has an executable and 
PIDfile-Parameter
            openVPN:
               also a heir of pidBaseAgent which has all the parameters a 
full-featured Debian-Openvpn-Server needs,

Here is the full source code of pidAgent:

from pidbaseagent import PIDBaseAgent

from inqbus.ocf.generic.parameter import OCFString

class PIDAgent(PIDBaseAgent):

    def config(self):
        """
        Define the two essential paramters
        """
        self.add_parameter(OCFString("executable",
                            longdesc="Path to the executable",
                            shortdesc="executable",
                            required= True) )
        self.add_parameter(OCFString( "pid_file",
                            longdesc="Path to the pid file",
                            shortdesc="executable",
                            required= True) )

    def get_pid_file(self):
        """tell the base class to find the PID file in the parameter 
'pid_file'"""
        return self.params.pid_file.value

    def get_executable(self):
        """tell the base class how to find the executable path in the parameter 
'executable'"""
        return self.params.executable.value

def main():
    """Entry point for the reasource agent shellscript"""
    import sys
    PIDAgent().run(sys.argv)

if __name__ == "__main__" : main()
    """Entry point for the command line"""

As you can see, all the gory details as dealing with the XML generation for the 
meta-data command are completly automagical and build into the
framework.
Also the complete business-Logic of dealing with PID-Files, Zombie-Processes, 
starting and stopping processes is delegated into the baseclass
PIDBaseAgent.

The framework is builded with test driven development with a test coverage of 
80 % of lines of code. The not covered 20% attribute to corner
cases like
defective Filesystems and not responsitive processes which are hard to simulate.
The OCF-Tester testcases are build into the framework. A friendly dummy_daemon 
is run as a real unix-process for testing on user level.
On Superuser-level testing invokes the real daemons. In case of the openvpn 
Agent a real openvpn instance is tested along the ocf-tester cases.

You may find the inqbus.ocf framework here

http://pypi.python.org/pypi/inqbus.ocf.agents
http://pypi.python.org/pypi/inqbus.ocf.generic

We are currently hardening the code while we are starting to bringing it into 
production. The code is fresh and may
contain some severe defects, despite of the good testing coverage.

We like to welcome the community to help us to improve the code be to become a 
open source cornerstone of the linux-HA project.

Best Regards

Volker


-- 
====================================================
   inqbus GmbH & Co. KG      +49 ( 341 ) 60013031
   Dr.  Volker Jaenisch      http://www.inqbus.de
   Karl-Heine-Str.   99      0 4 2 2 9    Leipzig
   N  O  T -  F Ä L L E      +49 ( 170 )  3113748
====================================================

_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to