- Doc Structure
- A Globus Primer
- Globus Is Modular!
- Installing GT
- Platform Notes
- Migrating from GT2
- Migrating from GT3
- PDF version
- Best Practices
- Coding Guidelines
- API docs
- Public Interfaces
- Resource Properties
- Performance Studies
Table of Contents
- 1. Introduction
- 2. Building and Installing
- 3. Configuring
- 4. Deploying
- 5. Testing
- 6. Security Considerations
- 7. Troubleshooting
This guide contains advanced configuration information for system administrators working with the WS MDS Trigger Service. It provides references to information on procedures typically performed by system administrators, including installation, configuring, deploying, and testing the installation.
This information is in addition to the basic Globus Toolkit prerequisite, overview, installation, security configuration instructions in GT 4.1.1 System Administrator's Guide. Read through this guide before continuing!
The Trigger Service is installed as part of the standard Globus Toolkit installation.
The trigger service is an MDS aggregator service, and so inherits much of its configuration system from the Aggregator Framework module.
The Aggregator Framework does not have its own service side configuration, although services which are based on the framework have their own service side configuration options (such as MDS Index and MDS Trigger") which are documented in the per-service documentation.
Registrations to a working Aggregator Framework are configured for the mds-servicegroup-add(1) tool. This tool takes an XML configuration file listing registrations, and causes those registrations to be made.
In general, configuration of aggregator services involves configuring the service to get information from one or more sources in a Grid. The mechanism for doing this is defined by (inherited from) the Aggregator Framework and described in this section.
Configuring an Aggregating Service Group to perform a data aggregation is performed by specifying an AggregatorContent object as the content parameter of a ServiceGroup add method invocation. An AggregatorContent object is composed of two xsd:any arrays: AggregatorConfig and AggregatorData:
- The AggregatorConfig xsd:any array is used to specify parameters that are to be passed to the underlying AggregatorSource when the ServiceGroup add method is invoked. These parameters are generally type-specific to the implementation of the AggregatorSource and/or AggregatorSink being used.
- The AggregatorData xsd:any array is used as the storage location for aggregated data that is the result of message deliveries to the AggregatorSink. Generally, the AggregatorData parameter of the AggregatorContent is not populated when the ServiceGroup add method is invoked, but rather is populated by message delivery from the AggregatorSource.
The following links provide information for configuring the three types of aggregator sources provided by the Globus Toolkit:
An aggregator sink may require sink-specific configuration (the MDS Trigger Service requires sink-specific configuration; the MDS Index Service does not). See the documentation for the specific aggregator service being used for details on sink-specific documentation.
It is now possible to disable the publishing of the aggregator configuration along with the aggregated data. The following optional parameter can be added to the AggregatorConfiguration section of the service
<parameter> <name>publishAggregatorConfiguration</name> <value>false</value> </parameter>
By default, this option is disabled and the aggregator configuration information is published.
In addition to the source parameters specified
TriggerRuleType element must be added to all registrations
made to the trigger service.
TriggerRuleType is defined in
This registration parameter contains the following options:
matchingRule: XPath rule to be applied against incoming data. The XPath expression will be evaluated against aggregated data, and will be regarded as matching the incoming data if it matches one or more nodes in that data.
namespaceMappings: An array of string namespace mappings in the form xmlns:foo=http://foo.bar. This array of namespace mappings will be used to resolve namespace prefixes used in the XPath matchingRule statement.
evaluateBoolean: If this parameter is present and set to true the service will interpret a boolean XPath query result as the trigger firing condition. A return value of true indicates that the trigger action will be fired, a return value of false will cause the trigger action to be suppressed. Note that other rate limiting parameters may still apply even if the query result is TRUE, and therefore trigger actions can still be suppressed even in those cases.
actionScript: the logical name of a script that will be executed when the matchingRule matches (except as rate limited). This logical name must be mapped to a physical file name located in the
$GLOBUS_LOCATION/libexec/trigger/directory. The logical-to-physical filename mapping is specified in the
executableMappingsparameter of the
triggerConfigurationblock of the file
minimumFiringInterval: the action script will not be executed more than once in this number of seconds. If unspecified, there will be no minimum interval.
minimumMatchTime: the matchingRule must be true for this number of seconds before the actionScript will be executed. If unspecified, there is no minimum time period that the rule must match and the rule will be eligible to fire immediately after the matchingRule becomes true.
invalidityTime: An array of TriggerInvalidityTime time ranges during which the trigger will not fire under any condition. If the current trigger fire time falls within any of the time ranges present in this variable, the trigger will not fire.
enableFilteredActionScriptInput: If this value is present and set to true, the service will pass the filtered output result of the XPath matchingRule as additional input to the stdin of the action script, in addition to the original input to which the matching rule was applied. The default behavior if unspecified is false, meaning the Xpath query result will not be passed as input to the action script.
disableUnmodifiedActionScriptInput: If this value is present and set to true the service will not pass the original trigger message input (to which the matching rule was applied) to the action script. The default behavior is to always pass the entire input message to the action scripts. For action scripts which do not need to consume the unmodified input, this variable may be set to true in order to increase performance.
outputXSL: (CURRENTLY UNIMPLEMENTED) The delivered message will be transformed by the specified XSLT stylesheet and fed into the stdin of the action script.
The rate limiting parameters behave in such a way that the rate of action
script executions can be decreased by increasing the
minimumFiringInterval and/or by increasing the
This component is deployed as part of the standard toolkit installation. By default, there are no trigger actions set to fire on container startup, as these must be configured and registered manually.
To manually register the example described in Configuring the Trigger Service (above) do the following:
- Configure your environment with either Ganglia or Hawkeye as described in the GLUE RP documentation. This is necessary because the trigger service relies on polling the GLUE RP which is provided by either one of them. Note: Even without configuring Ganglia or Hawkeye, the GLUE RP is emitted by the scheduler configured for your environment, so this step is not strictly necessary.
Now you can start your container as you normally do by running:
At this point, we're ready to make a registration with the
DefaultTriggerServiceby running a command similar to the following:
$GLOBUS_LOCATION/bin/mds-servicegroup-add -s \ https://127.0.0.1:8443/wsrf/services/DefaultTriggerService \ $GLOBUS_LOCATION/etc/globus_wsrf_mds_trigger/trigger-aggregator-registration.xml
You should see output similar to the following if your environment has been configured properly:
Processing configuration file... Processed 1 registration entries Successfully registered https://127.0.0.1:8443/wsrf/services/ManagedJobFactoryService to servicegroup at https://127.0.0.1:8443/wsrf/services/DefaultTriggerService
The WS MDS Trigger Service has been tested to work without any additional setup when deployed into Tomcat. Please follow these basic instructions to deploy GT4 services into Tomcat. Note: please complete any prerequisite service configuration steps before you deploy into Tomcat.
To determine if the registration was made properly, you can query the
DefaultTriggerService using a tool like
$GLOBUS_LOCATION/bin/wsrf-query and visually inspect the
For example, running:
$GLOBUS_LOCATION/bin/wsrf-query -s \ https://127.0.0.1:8443/wsrf/services/DefaultTriggerService "/*"
should yield output similar to the following for the example above:
... <ns1:Content xsi:type="ns11:AggregatorContent" xmlns:ns11="http://mds.globus.org/aggregator/types"> <ns11:AggregatorConfig> <ns11:GetResourcePropertyPollType> <ns11:PollIntervalMillis>600000</ns11:PollIntervalMillis> <ns11:ResourcePropertyName>glue:GLUECE</ns11:ResourcePropertyName> </ns11:GetResourcePropertyPollType> <ns3:TriggerRuleType xmlns:ns3="http://mds.globus.org/2004/08/trigger/types"> <ns3:matchingRule>//*[local-name()='GLUECE']</ns3:matchingRule> <ns3:actionScript>glue-trigger-action.sh</ns3:actionScript> <ns3:minimumFiringInterval>600</ns3:minimumFiringInterval> </ns3:TriggerRuleType> </ns11:AggregatorConfig> <ns11:AggregatorData> <ns12:TriggerStatus> <ns12:conditionTrueSince>2005-04-11T16:31:00.501Z</ns12:conditionTrueSince> <ns12:actionFiredAt>2005-04-11T16:31:00.656Z</ns12:actionFiredAt> <ns12:ruleLastCheckedAt>2005-04-11T16:31:00.493Z</ns12:ruleLastCheckedAt> <ns12:actionOutput> <exampleGLUETriggerActionScriptOutput xmlns=""> <glueDataDetected>true</glueDataDetected> </exampleGLUETriggerActionScriptOutput> </ns12:actionOutput> </ns12:TriggerStatus> </ns11:AggregatorData> </ns1:Content> ...
The included sample trigger script not only emits some XML data as seen above
actionOutput node, but it also attempts to append
some data to a file each time it is fired. Thus, to be sure it is working properly,
you can inspect the file
/tmp/glue_detected by running a
which should yield output similar to this:
GLUECE RP was detected in the output at Mon Apr 11 11:01:01 CDT 2005 GLUECE RP was detected in the output at Mon Apr 11 11:11:00 CDT 2005 GLUECE RP was detected in the output at Mon Apr 11 11:21:00 CDT 2005 GLUECE RP was detected in the output at Mon Apr 11 11:31:00 CDT 2005 GLUECE RP was detected in the output at Mon Apr 11 11:41:00 CDT 2005
The security considerations for the Aggregator Framework also apply to the Trigger Service:
By default, the aggregator sources do not use authentication credentials -- they retrieve information using anonymous SSL authentication or no authentication at all, and thus retrieve only publicly-available information. If a user or administrator changes that configuration so that a service's aggregator source uses credentials to acquire non-privileged data, then that user or administrator must configure the service's aggregator sink to limit access to authorized users.
Problem: I'm sure the registration was made properly, but the trigger script never fires.
Solution: Verify that you've properly configured the GLUE RP output via Ganglia or Hawkeye. Even a properly made trigger registration will never fire if the GLUE RP cannot be produced.