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:
/usr/sbin/ocft) — generates shell
scripts from test case configuration files
/usr/share/resource-agents/ocft/configs/) — a configuration file contains environment setup and test cases
for one resource agent
/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.
AgentRoot (sub-option)
AgentRoot /usr/lib/ocf/resource.d/xxx
Normally, we assume that the resource agent lives under the
heartbeat provider. Use AgentRoot to test agent which is
distributed by another vendor.
InstallPackage (sub-option)
InstallPackage package [package2 [...]]
Install packages necessary for testing. The installation is skipped if the packages have already been installed.
HangTimeout secs
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.
CASE "description"
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
RunAgent suboption.
Var (sub-option)
Var VARIABLE=value
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 (sub-option)
Unvar VARIABLE [VARIABLE2 [...]]
Remove the environment variable.
Include (sub-option)
Include macro_name
Include statements in macro_name. See below for description of
CASE-BLOCK.
Bash (sub-option)
Bash bash_codes
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.
BashAtExit (sub-option)
BashAtExit bash_codes
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 (sub-option)
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:
Bash@192.168.1.100 date
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.