The resource agents repository (and hence, any installed resource agents package) contains a utility named
ocf-tester. This shell script allows you to conveniently and easily test the functionality of your resource agent.
ocf-tester is commonly invoked, as
root, like this:
ocf-tester -n <name> [-o <param>=<value> ... ] <resource agent>
<name>is an arbitrary resource name.
- You may set any number of
-ooption, corresponding to any resource parameters you wish to set for testing.
<resource agent>is the full path to your resource agent.
ocf-tester executes all mandatory actions and enforces action behavior as explained in Section 5, “Resource agent actions”.
It also tests for optional actions. Optional actions must behave as expected when advertised, but do not cause
ocf-tester to flag an error if not implemented.
For example, you could run
ocf-tester on the
foobar resource agent as follows:
# ocf-tester -n foobartest \ -o superfrobnicate=true \ -o datadir=/tmp \ /home/johndoe/ra-dev/foobar Beginning tests for /home/johndoe/ra-dev/foobar... * Your agent does not support the notify action (optional) * Your agent does not support the reload action (optional) /home/johndoe/ra-dev/foobar passed all tests
ocft is a testing tool for resource agents. The main difference to
ocf-tester is that
ocft can automate creating complex testing environments. That includes package installation and arbitrary shell scripting.
ocft consists of the following components:
- A test case generator (
/usr/sbin/ocft) — generates shell scripts from test case configuration files
- Configuration files (
/usr/share/resource-agents/ocft/configs/) — a configuration file contains environment setup and test cases for one resource agent
- The testing scripts are stored in
/var/lib/resource-agents/ocft/cases/, but normally there is no need to inspect them
ocft modifies the runtime environment of the resource agent either by changing environment variables (through the interface defined by OCF) or by running ad-hoc shell scripts which can for instance change permissions of a file or unmount a file system.
You need to know the software (resource) you want to test. Draw a sketch of all interesting scenarios, with all expected and unexpected conditions and how the resource agent should react to them. Then you need to encode these conditions and the expected outcomes as
ocft test cases. Running ocft is then simple:
# ocft make <RA> # ocft test <RA>
The first subcommand generates the scripts for your test cases whereas the second runs them and checks the outcome.
There are four top level options each of which can contain one or more sub-options.
This option is global and influences every test case.
Normally, we assume that the resource agent lives under the
heartbeat provider. Use
AgentRoot to test agent which is distributed by another vendor.
InstallPackage package [package2 [...]]
Install packages necessary for testing. The installation is skipped if the packages have already been installed.
- HangTimeout (sub-option)
The maximum time allowed for a single RA action. If this timer expires, the action is considered as failed.
SETUP-AGENT bash commands
If the RA needs to be initialized before testing, you can put bash code here for that purpose. The initialization is done only once. If you need to reinitialize then delete the
/tmp/.[AGENT_NAME]_set stamp file.
This is the main building block of the test suite. Each test case is to be described in one
CASE top level option.
One case consists of several suboptions typically followed by the
It is to set up an environment variable of the resource agent. They usually appear to be OCF_RESKEY_xxx. One point is to be noted is there is no blank by both sides of “=”.
Unvar VARIABLE [VARIABLE2 [...]]
Remove the environment variable.
Include statements in macro_name. See below for description of
This option is to set up the environment of OS, where you can insert BASH code to customize the system randomly. Note, do not cause unrecoverable consequences to the system.
This option is to recover the OS environment in order to run another test case correctly. Of cause you can use Bash option to recover it. However, if mistakes occur in the process, the script will quit directly instead of running your recovery codes. If it happens, you ought to use BashAtExit which can restore the system environment before you quit.
RunAgent cmd [ret_value]
This option is to run resource agent. “cmd” is the parameter of the resource agent, such as “start, status, stop …”. The second parameter is optional. It will compare the actual returned value with the expected value when the script has run recourse agent. If differs, bugs will be found.
It is also possible to execute a suboption on a remote host instead of locally. The protocol used is ssh and the command is run in the background. Just add the
@<ipaddr> suffix to the suboption name. For instance:
would run the date program. Remote commands are run in background.
NB: Not clear how can ssh be automated as we don’t know in advance the environment. Perhaps use “well-known” host names such as “node2”? Also, if the command runs in the background, it’s not clear how is the exit code checked. Finally, does Var@node make sense? Or is the current environment somehow copied over? We probably need an example here.
Need examples in general.