Using Hudson SmartFrog plugin

The aim of this document is to help you with setting up automated SmartFrog tests using Hudson. This document assumes that you are familiar with SmartFrog environment. If not, I would recommend you to go through excellent SmartFrog documentation available on SmartFrog homepage.

Notes

This document as well as the plugin itself are in development, so things may eventually change. However, we think that it is allready in usable state. In any case, your feedback is highly appreciated. Please write do dpospisi@redhat.com.

Plugin features

• spawn SmartFrog daemons on all target hosts

• deploy SmartFrog component on selected host

• monitor the deployment

• collect daemons' output and present it through Hudson interface

Planned features

• propagate deploy hosts to SmartFrog components

• gather artifacts from deploy hosts

Availability

Now the plugin is installed on main Hudson instance.

Implementation notes

As of now, Hudson does not allow a job to be executed on multiple boxes. Therefore, deployment target hosts do not act as Hudson slaves and from the Hudson perspective, the job execution is still being performed on a single box. As a result this plugin does not provide real scheduling capabilities. This is indeed a serious limitation and should be addressed in the future. However the plugin tries to start new SF instance on all hosts before initiating componenet deployment. And since there could be only one daemon running on the same host in the same time, each attempt to start a new deployment on a host which is allready running SF daemon will fail. So this provides some limited sort of sheduling.

Target hosts

As mentioned above, a target host does not have to be necessarily configured as Hudson slave. However hudson system user needs to have SSH access to target host. This holds for:

• all machines configured as Hudson slaves

• cluster lab - cluster01, ..., cluster10

• perf lab - perf01, ..., perf10

Job Configuration

• create a free-form project and check "Deploy SmartFrog component" in job configuration

• SmartFrog instance - select an instance of SmartFrog environment. List of instances could be altered at Hudson -> Manage Hudson -> System Configuration

• Deploy host - the name of the host for the initial deployment

• Target hosts - list of host names of all boxes on which the build will be performed. Must include deploy host

• SFUSERHOME - path to a directory containing one or more jars with SF-components classes; the path is relative to the job workspace

• JVM_ARGS - java command line arguments to be passed to JVM when invoking SF daemons

• SFDEFAULTINI - SmartFrog configuration file override

• Deployment name - SF name of the deployed component; choose whatever you wish

• Get description from file - select if you want the SF script to be loaded from file

• Specify component description - select if you wish to write SF script to project configuration page

SmartFrog components

There is a bunch of JBoss specific components developed by our QA resources available at https://svn.corp.jboss.com/repos/qa/benchmarking/smartfrog/. This components provides features such as:

• starting/stopping JBoss AS

• managing JBoss cluster

• basic reporting

• load testing

Complete description is out of the scope of this document.

Examples

There is a list of working projects available at http://hudson.qa.jboss.com/hudson/view/EAP Perf+Fail/. Use them as a reference if you want to write new tests and/or migrate existing ones to Hudson.