For every application that needs to be deployed as an Opal service, you will need to create an Opal configuration file. A sample configuration file for the command /bin/date, located in $OPAL_HOME/configs/date_config.xml, is shown below.
<appConfig xmlns="http://nbcr.sdsc.edu/opal/types"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<metadata>
<usage><![CDATA[date [-u] mmddhhmm[[cc]yy]]]></usage>
</metadata>
<binaryLocation>/bin/date</binaryLocation>
<defaultArgs></defaultArgs>
<validateArgs>false</validateArgs>
<jobManagerFQCN>edu.sdsc.nbcr.opal.manager.ForkJobManager</jobManagerFQCN>
<parallel>false</parallel>
</appConfig> |
The configuration consists of a top level element appConfig, which contains metadata, binaryLocation, defaultArgs, parallel, validateArgs, and jobManagerFQCN elements. The metadata consists of usage, which is a string specifying how the application is to be invoked, and an array of optional application information specified as info elements. It also contains an optional types element, which we can ignore for now (more information about the types element can be found from our Advanced Submission Form page). In the above file, the various options that can be used with the application are specified within the metadata.
The binaryLocation specifies the location of the application binary - note that this has to be the location of a single executable. No arguments may be specified here. However, default arguments that need to be used for every run can be specified inside the defaultArgs element. The parallel element specifies if an application is parallel or not. The validateArgs and jobManagerFQCN elements are optional. If set to true, the validateArgs element instructs Opal to use the optional command-line specification (within types) to validate arguments prior to execution. The jobManagerFQCN element over-rides the default job manager, and can be set to the fully qualified classname of an Opal job manager. By default, the FQCNs for job managers provided by Opal are edu.sdsc.nbcr.opal.manager.ForkJobManager (for basic fork/system exec), edu.sdsc.nbcr.opal.manager.DRMAAJobManager (for DRMAA), edu.sdsc.nbcr.opal.manager.GlobusJobManager (for Globus on a local cluster), edu.sdsc.nbcr.opal.manager.RemoteGlobusJobManager (for Globus job submissions to a remote cluster), edu.sdsc.nbcr.opal.manager.CondorJobManager (for submitting jobs directly to Condor) and edu.sdsc.nbcr.opal.manager.CSFJobManager (for using the Community Scheduler Framework). Use the pdb2pqr_config.xml as a guideline to write configurations for your particular applications.
For a more detailed application configuration, including specification of the command-line arguments, please see Sample Application Configuration File.
Deploy the services inside Tomcat, by changing to the $OPAL_HOME directory, and running the following command:
$ANT_HOME/bin/ant deploy -DserviceName=<serviceName> -DappConfig=<appConfig> |
For example, to deploy the Date service, you would type the following command:
$ANT_HOME/bin/ant deploy -DserviceName=DateService \
-DappConfig=$PWD/configs/date_config.xml |
If the service is deployed successfully, it can be accessed programmatically at URL: http://host:port/opal2/services/serviceName, or via the Web-based Opal Dashboard at URL: http://host:port/opal2/dashboard.
You can undeploy your service at any time by running the following command:
$ANT_HOME/bin/ant undeploy -DserviceName=<serviceName> |
Both the deploy and undeploy targets accept a -DappVersion parameter. If this is used, the service URL deployed is of the form serviceName_appVersion.
If you plan on using the service with large inputs and outputs, it is a good idea to increase the heap size being used by the JVM. This can be done by setting the JAVA_OPTS environment variable to -Xmx1024m, and restarting Tomcat. This increases the heap size to 1GB. If all went well until this step, the services are running and ready to be used. Test them by running the client, described in the following section.
The service creates new working directories for every execution. These working directories are not deleted automatically, so they must be periodically cleaned up. You may use the script $OPAL_HOME/etc/cleanup.sh to do so - you will have to modify it to point to your Tomcat installation (and optionally modify the number of days to retain scratch directories).