7. Writing Custom Data Consumers
The default Inca consumers described in Section 6.7 are created by fetching XML report data from the Inca depot and applying XSL and JSP to produce HTML tables and graphs. XML can be fetched for specific Inca suites (or stored queries), resources, series and time frames. A number of methods are available for fetching Inca XML: REST URLs, Inca Client APIs, and Web Services. The different types of XML returned from these methods are described in Section 7.1.
Once custom XML is retrieved (see Section 7.2), addtional XSL can be created to display the results according to individual requirements or the XML can be consumed by custom JSPs or other code. Examples of XSL and JSPs are located in the webapps/inca/xsl and webapps/inca/jsp directories respectively. Below are some examples of the way XML can be transformed to produce the basic status pages.
Figure 18 shows an example of XML that is transformed via XSL to produce a pass/fail table of test results. The XML is an array of report summaries, which are the result of querying for a suite or stored query. The exit status or body of each report summary is matched to a resource by the XSL to show the latest result for each resource. If the report summary has a comparison result, it will be used instead of the exit status to determine whether the test passed or failed. Comparison results are checks that are added before the report is stored - one example might be checking whether the software version found in the report was greater than a certain version number.
Another consumer example using report summaries XML is shown in Figure 19. Here the XML is transformed via XSL to produce a table of performance results. Like the pass/fail table, the XSL matches results and resources, but here XPath is used to display a statistic in the body instead of a pass/fail exit status.
Simple pass/fail graphs are produced by transforming the graph instance XML as shown in Figure 20. The graph is produced by using the exit status values for the y-axis and the collected date values for the x-axis.
The w3schools site offers an XSL tutorial and an XPath tutorial for more general information about XSL and XPath.
7.1. Understanding Inca XML Data
Inca reporters are executable programs that measure some aspect of the system or installed software. Reporters support a set of command-line options and write XML reports to stdout. The report schema is flexible and can capture multiple types of data.
The XML document produced by Inca reporters is called a report and it has a header, body and footer. The header contains metadata, the body contains the data collected by the reporter and has a 4000 character limit, and the footer captures whether the report was successfully gathered or not:
Most of the Inca XML types relate to the basic report type. Some definitions to help understand the XML schemas are:
- report series (or series for short)
set of reports collected at different points in time by executing a reporter with a set of arguments in a context on a particular resource
- series config
used to create the report series and has hostname, args, reporter name/version, schedule, comparitor (extra check to determine pass/fail), and context (optional string used when executing the reporter, e.g. to add a softenv key: "soft add +atlas; cluster.math.atlas.version -args")
- suite
group of series configs that share a common theme, for example data management, job management, or file transfer
- resource group
two or more related resources that share a characteristic like a site, architecture or virtual organization. A resource can be a cluster, supercomputer, or server. The resource group XML is returned along with queries so that they can be matched to test results. Below is a figure to illustrate resource groups:
- runtime data
in addition to the main body of data returned by reports, other runtime information is calculated after the report is executed and returned with it. This data includes logged commands, usage information (how much memory, CPU and wallclock time a reporter consumes during execution) and comparison results (extra tests used to calculate whether a test passed or fails, e.g. whether the software version found matches a version requirement)
An important concept within Inca is the comparitor. As shown above, every report has an exitStatus to indicate whether an Inca reporter was able to complete successfully or not. For reporters that are more complex, the exitStatus may not be sufficient. For example, a version reporter may successfully collect the version of GCC but the version collected may be too old. Or a performance reporter may successfully collect the bandwidth of a GridFTP transfer but the bandwidth is so low that it could be considered a failure. In these cases, a comparitor can be used to interpret a reporter result. For a version reporter, a simple comparitor would be for example:
gcc >= 4.2 |
For a performance reporter, a simple comparitor would be for example:
bandwidthMB >= 100 |
When a comparitor is specified by an Inca administrator, an additional field, comparisonResult, is returned with the Inca data and contains either a 'Success' or 'Failure:reasons' value. The reason value will be the part of the comparitor that failed, e.g., gcc or bandwidthMB.
A comparitor is also specified when an Inca administrator sets up email notification on a series. Therefore a common comparitor is to check that the errorMessage is empty as shown below:
errorMessage=='' |
If a report with an error is sent to the depot, the errorMessage will be set causing the comparitor to fail and an email notification to be sent.
In summary, when interpreting the result of a report, first check to if a comparisonResult exists. If it does, then use that value. Otherwise, use the body or errorMessage to interpret the result. Please see pseudo-code below for an example:
if ( exists comparisonResult ) {
if ( comparisonResult == 'Success' ) {
println "Pass"
} else {
println "Failed: " + comparisonResult;
if ( exists errorMessage ) {
println errorMessage;
}
}
} else {
if ( body != '' ) { // or you could use if ( errorMessage == '' )
println "Pass";
} else {
println errorMessage;
}
} |
Below is an example of a series that gets a version of gcc. The series originally has a comparitor that requires a specific version of gcc (>=4.2). The series fails until the comparitor requirement is removed.
Inca depot query results are formatted as XML, most are an array of reporter execution summary, graph or detail information. These results can be retrieved from the REST, JSP, Client and Web services interfaces described in Section 7.2.
7.1.1. Report Summaries
Report summaries return XML formatted like the following (tags are described below):
<reportSummary xmlns="http://inca.sdsc.edu/queryResult/reportSummary_2.0"> <hostname xmlns="">localResource</hostname> <targetHostname xmlns=""/> <uri xmlns="">file:///Inca-Reporter-5.12450/bin/cluster.compiler.any.unit</uri> <nickname xmlns="">java_hello_world</nickname> <seriesConfigId xmlns="">5</seriesConfigId> <instanceId xmlns="">49</instanceId> <gmt xmlns="">2010-06-08T15:25:01.000-07:00</gmt> <gmtExpires xmlns="">2010-06-08T15:45:01.027-07:00</gmtExpires> <body xmlns=""> <unitTest xmlns:rep="http://inca.sdsc.edu/dataModel/report_2.1"> <ID>javac</ID> </unitTest> </body> <errorMessage xmlns=""/> <comparisonResult xmlns="">Success</comparisonResult> </reportSummary> |
Report summaries use a prefix with a tag name that references the http://inca.sdsc.edu/queryResult/reportSummary_2.0 namespace.
The following tags are defined within query results:
- hostname
resource id where the reporter executed
- targetHostname
resource id of the resource group whose macros were used in configuring the report series. For example, if a reporter executes on resource A, but it uses macros from resource B to get a hostname parameter for the test, the resource id for resource B will be the targetHostname.
- uri
the URI of the reporter repository and the location of the reporter
- nickname
the nickname (short name) for the report series
- seriesConfigId
(internal) the database identifier for the series configuration information for this report summary (used in further queries)
- instanceId
(internal) the database identifier for the instance information for the particular time this report series executed (used in further queries)
- gmt
the time this report series executed (ISO 8601 format)
- gmtExpires
the time when results from this report will become stale (ISO 8601 format)
- body
results of the reporter's testing
- errorMessage
optional string indicating why the reporter failed to complete
- comparisonResult
if series was configured with a comparison, the result of the comparison for this particular report series execution
7.1.2. Graph Instances
Graph instances return XML formatted like the following (tags are described below):
<row> <resource>sapa</resource> <nickname>cvs_repo</nickname> <instanceId>41518967</instanceId> <reportId>20958820</reportId> <configId>20437465</configId> <collected>2010-06-01T00:11:03.000-07:00</collected> <exit_status>0</exit_status> <exit_message/> <body xmlns:rep="http://inca.sdsc.edu/dataModel/report_2.1"/> <comparisonResult>Success</comparisonResult> </row> |
Graph instances use a prefix with a tag name that references the http://inca.sdsc.edu/dataModel/graphSeries_2.0 namespace.
The following tags are defined within query results:
- resource
resource id where the reporter executed
- nickname
the nickname (short name) for the report series
- instanceId
(internal) the database identifier for the instance information for the particular time this report series executed (used in further queries)
- reportId
(internal) the database identifier for the report information for the particular result from this report series (used in further queries)
- configId
(internal) the database identifier for the series configuration information for this report summary (used in further queries)
- collected
the time this report series executed (ISO 8601 format)
- exit_status
boolean indicating whether or not the reporter successfully completed its testing
- exit_message
optional string indicating why the reporter failed to complete
- body
results of the reporter's testing
- comparisonResult
if series was configured with a comparison, the result of the comparison for this particular report series execution
7.1.3. Report Details
The individual report details are generated by a depot query that returns XML formatted like the following (tags are described below):
<reportDetails xmlns="http://inca.sdsc.edu/dataModel/reportDetails_2.1">
<suiteId xmlns="">8140012</suiteId>
<seriesConfigId xmlns="">8156370</seriesConfigId>
<seriesId xmlns="">1712066</seriesId>
<reportId xmlns="">28430963</reportId>
<instanceId xmlns="">30977056</instanceId>
<seriesConfig xmlns="">
<series>
<name>cluster.compiler.gcc.version</name>
<version>2</version>
<uri>http://inca.sdsc.edu/2.0/ctssv3/bin/cluster.compiler.gcc.version</uri>
<args>
<arg>
<name>log</name>
<value>5</value>
</arg>
<arg>
<name>version</name>
<value>no</value>
</arg>
<arg>
<name>help</name>
<value>no</value>
</arg>
<arg>
<name>verbose</name>
<value>1</value>
</arg>
</args>
<limits>
<wallClockTime>600.0</wallClockTime>
<memory>-1.0</memory>
<cpuTime>-1.0</cpuTime>
</limits>
<context><![CDATA[bash -l -c 'set -a; cd /usr/users/9/inca/inca2install; export PERL5LIB=/usr/users/9/inca/inca2install/var/reporter-packages/lib/perl:${HOME}/inca/install/lib/perl &&cluster.compiler.gcc.version -help="no" -log="5" -verbose="1" -version="no";';]]></context>
<nice>false</nice>
</series>
<nickname>compiler-gnu-version-as-4.0.1</nickname>
<resourceHostname>psc-bigben</resourceHostname>
<schedule>
<cron>
<min>2</min>
<hour>17</hour>
<mday>*</mday>
<wday>*</wday>
<month>*</month>
</cron>
<numOccurs>-1</numOccurs>
<suspended>false</suspended>
</schedule>
<acceptedOutput>
<comparitor>ExprComparitor</comparitor>
<comparison>gcc=~".*"</comparison>
<notifications>
<notification>
<notifier>EmailNotifier</notifier>
<target>FailTo:inca@sdsc.edu</target>
</notification>
</notifications>
</acceptedOutput>
<action>add</action>
</seriesConfig>
<report xmlns="">...</report>
<comparisonResult xmlns="">Success</comparisonResult>
<sysusage xmlns="">
<wallClockTime>0.929562</wallClockTime>
<memory>0.0</memory>
<cpuTime>0.556034</cpuTime>
</sysusage>
<stderr xmlns=""/>
</reportDetails> |
Report detail output is surrounded by <reportDetails> tags. A prefix with a tag name that references http://inca.sdsc.edu/dataModel/reportDetails_2.1, which is the namespace that defines the report schema, can also be used.
The following tags are defined within a <reportDetails>:
- suiteId
(internal) the database identifier for the suite id number this report series belongs to (used in further queries)
- seriesConfigId
(internal) the database identifier for the series configuration information for this report series (used in further queries)
- seriesId
(internal) the database identifier for the series information for this report series (used in further queries)
- reportId
(internal) the database identifier for the report information for the particular result from this report series (used in further queries)
- instanceId
(internal) the database identifier for the instance information for the particular time this report series executed (used in further queries)
- seriesConfig
all of the configuration options for this report series: name (of reporter), version (of reporter), uri (for reporter), args, limits (for consumption of wall clock time, memory, and cpu time), context (command to execute series), nickname (of series), resourceHostname (where series will execute), schedule (cron for executing series), acceptedOutput (can include "comparison" string to match in the report and "notification" actions to take if the comparison fails)
- report
report XML like that described in Section 8.2.2
- comparisonResult
if series was configured with a comparison, the result of the comparison for this particular report series execution
- sysusage
amount of wall clock time, memory and cpu time this particular report series execution consumed
- stderr
standard error, if any, for this particular report series execution
7.2. Retrieving Data
7.2.1. REST APIs
The simplest way to retrieve Inca data is through its REST APIs. By default, the consumer recognizes a REST URL using the following format:
http://localhost:8080/inca/XML|HTML/rest/<suiteName>|<queryName>[/<resourceId>[/<seriesNickname>[/<timestamp>|week|month|quarter|year]]]
Note the rest keyword may be vary by Inca deployment. Please check with your Inca administrator for a non-default keyword.
Table 5. Examples of Inca REST URLs
REST URL | Returns |
|---|---|
Returns the latest results for the specified suite (or query) as an array of report summaries. | |
Returns the latest results for the specified suite (or query) and resource or resource group as an array of report summaries. | |
http://localhost:8080/inca/XML/rest/sampleSuite/localResource/ant_version | Returns the latest details for a specific series within the specified suite and resource according to the report details schema |
Returns the details of the instance executed at the given timestamp for a specific series within the specified suite and resource according to the report details schema | |
http://localhost:8080/inca/XML/rest/sampleSuite/localResource/ant_version/week | Returns the last week of historical results for the specified series as an array of graph instances. |
http://localhost:8080/inca/XML/rest/sampleSuite/localResource/ant_version/month | Returns the last month of historical results for the specified series as an array of graph instances. |
http://localhost:8080/inca/XML/rest/sampleSuite/localResource/ant_version/quarter | Returns the last quarter (3 months) of historical results for the specified series as an array of graph instances. |
http://localhost:8080/inca/XML/rest/sampleSuite/localResource/ant_version/year | Returns the last year of historical results for the specified series as an array of graph instances. |
For example, if you fetch the first REST URL specified above using the wget command, it would look like the following:
wget -O - http://rocks-101.sdsc.edu:8080/inca/XML/rest/sampleSuite
--09:24:30-- http://rocks-101.sdsc.edu:8080/inca/XML/rest/sampleSuite
=> `-'
Resolving rocks-101.sdsc.edu... done.
Connecting to rocks-101.sdsc.edu[198.202.88.101]:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6,990 [text/xml]
0% [ ] 0 --.--K/s ETA --:--
...
<quer:object
xmlns:quer="http://inca.sdsc.edu/dataModel/queryResults_2.0"><row><reportSummary
xmlns="http://inca.sdsc.edu/queryResult/reportSummary_2.0">
<hostname xmlns="">localResource</hostname>
<targetHostname xmlns=""/>
<uri
xmlns="">file:///home/inca/2.6/./bin/../Inca-Reporter-5.13359/bin/grid.wget.unit</uri>
<nickname xmlns="">wget_page_test</nickname>
<seriesConfigId xmlns="">1</seriesConfigId>
<instanceId xmlns="">1053</instanceId>
<gmt xmlns="">2010-08-24T09:20:02.000-07:00</gmt>
<gmtExpires xmlns="">2010-08-24T09:40:02.963-07:00</gmtExpires>
<body xmlns="">
<unitTest xmlns:rep="http://inca.sdsc.edu/dataModel/report_2.1">
<ID>wget</ID>
</unitTest>
</body>
<errorMessage xmlns=""/>
</reportSummary></row>...<row><reportSummary
xmlns="http://inca.sdsc.edu/queryResult/reportSummary_2.0">
<hostname xmlns="">localResource</hostname>
<targetHostname xmlns=""/>
<uri
xmlns="">file:///home/inca/2.6/./bin/../Inca-Reporter-5.13359/bin/cluster.admin.ant.version</uri>
<nickname xmlns="">ant_version</nickname>
<seriesConfigId xmlns="">10</seriesConfigId>
<instanceId xmlns="">1055</instanceId>
<gmt xmlns="">2010-08-24T09:22:03.000-07:00</gmt>
<gmtExpires xmlns="">2010-08-24T09:42:03.987-07:00</gmtExpires>
<body xmlns="">
<package xmlns:rep="http://inca.sdsc.edu/dataModel/report_2.1">
<ID>ant</ID>
<version>1.6.5</version>
</package>
</body>
<errorMessage xmlns=""/>
</reportSummary></row></quer:object>
100%[==================================>] 6,990 273.05K/s ETA 00:00
09:24:30 (273.05 KB/s) - `-' saved [6990/6990]
|
7.2.2. Web Services API
To query the Inca data via an API interface, you can utilize the Inca Web Services API. Please check with your Inca administrator first to check that the Web Services component is installed as described in Section 9. Next either ask your Inca administrator for the WSDL file for their deployment or download it directly from the Inca releases directory here. Then find the Inca Web Services hostname and port from your Inca administrator and edit the following portion of the file.
...
<port binding="tns:IncaWS_Binding" name="IncaWS_Port">
<soap:address location="http://localhost:8001"/>
</port>
... |
The Web Services API encompasses a subset of the client APIs described in Section 7.2.3. Documentation for the API can be found in the below link:
http://inca.sdsc.edu/releases/2.6/wsdocs/IncaWS_wsdl.html
The following shows an example of how to access the Inca web services from Perl using the Perl module SOAP::Lite.
use SOAP::Lite;
use Cwd;
my $cwd = getcwd();
my $ws = SOAP::Lite->service("file:$cwd/etc/IncaWS.wsdl");
# check agent and depot are available
print $ws->pingAgent('hello agent'), "\n";
print $ws->pingDepot('hello depot'), "\n";
# get the Inca configuration
print $ws->getConfig(), "\n";
my $guid = $ws->queryGuids();
# get the latest instances of a suite
my $results = $ws->querySuite( $guid );
for my $result ( @{$results} ) {
print $result;
} |
Place the above code in a file called $INCA_DIST/sampleWS.pl and edit the highlighted portion to reflect the location of the IncaWS.wsdl file. Set the environment variable PERL5LIB reflect the location of the SOAP::Lite library if it is not installed in the default path. Or if you are on the same machine as the Inca server, set it to $INCA_DIST/lib/perl. Then type,
% perl sampleWS.pl |
When run against the default installation, the results should look similar to below.
hello agent
hello depot
<inca:inca xmlns:inca="http://inca.sdsc.edu/dataModel/inca_2.0">
<repositories>
<repository>http://inca.sdsc.edu/repository/latest</repository>
</repositories>
<resourceConfig>
<resources>
<resource>
<name>defaultGrid</name>
<xpath>//resource[matches(name, "localSite")]</xpath>
<macros>
...
</resources>
</resourceConfig>
<suites>
<suite>
<seriesConfigs>
<seriesConfig>
<series>
<name>cluster.math.atlas.version</name>
<uri>http:// ... cluster.math.atlas.version</uri>
<args>
<arg>
<name>cc</name>
<value>cc</value>
</arg>
<arg>
<name>dir</name>
<value/></arg>
<arg>
<name>help</name>
<value>no</value>
</arg>
<arg>
<name>log</name>
<value>3</value>
</arg>
<arg>
<name>verbose</name>
<value>1</value>
</arg>
...
<action>add</action>
</seriesConfig>
</seriesConfigs>
<name>sampleSuite</name>
<guid>incas://rocks-101.sdsc.edu:6323/sampleSuite</guid>
<description/>
<version>1</version>
</suite>
</suites>
</inca:inca>
<reportSummary xmlns="http://inca.sdsc.edu/queryResult/reportSummary_2.0">
<hostname xmlns="">localResource</hostname>
<targetHostname xmlns=""/>
<uri xmlns="">http:// ... cluster.math.atlas.version</uri>
<nickname xmlns="">atlas_version</nickname>
<seriesConfigId xmlns="">1</seriesConfigId>
<instanceId xmlns="">24</instanceId>
<gmt xmlns="">2007-02-01T13:21:01.000-08:00</gmt>
<body xmlns:rep="http://inca.sdsc.edu/dataModel/report_2.1" xmlns=""/>
<errorMessage xmlns="">Cannot locate ATLAS installation; use
-dir</errorMessage>
</reportSummary>
... |
7.2.3. Inca Client APIs
An alternate method of accessing Inca data is through the the Inca Agent and Depot Client APIs. You can use this method if the Inca deployment is setup without authentication or by acquiring a set of credentials from your Inca administrator.
Currently, we provide Perl and Java client APIs to the Inca agent and depot. A number of the API functions return XML that can be used in custom Inca data consumers. For example, the DepotClient's queryInstance, queryLatest, and queryPeriod functions respectively return the report details, report summary, and graph instance XML document types described in Section 7.1. A summary of the available APIs and links to further documentation is shown in the below table.
7.2.3.1. Inca Perl Client APIs
The Perl Client API can be accessed on the Inca server at $INCA_DIST/lib/perl or by downloading the incaws tar ball, Inca-WS.tar.gz. To install Inca-WS.tar.gz, perform the following steps.
Untar the Inca-WS.tar.gz file
% tar zxvf Inca-WS.tar.gz
Install the module using the following command where $PREFIX indicates the desired destination directory.
% cd Inca-WS-* % perl Makefile.PL PREFIX=$PREFIX LIB=$PREFIX/lib/perl % make % make install
Copy the credentials from your Inca administrator over to the new installation. The file trusted.0 will actually be the hash of the CA certificate and will look something like 51b63f6c.0.
% mkdir $PREFIX/etc; mkdir $PREFIX/etc/trusted % cp clientcert.pem $PREFIX/etc % cp clientkey.pem $PREFIX/etc % cp trusted.0 $PREFIX/etc/trusted
Below is a sample of code using the Perl APIs that pings the Agent and queries for its configuration.
#!/usr/bin/perl
use strict;
use warnings;
use Inca::AgentClient;
print "Please enter a password: ";
chomp( my $pass = <STDIN> );
my $agentclient = new Inca::AgentClient(
host => 'localhost',
port => 6323,
auth => 1,
cert => 'etc/clientcert.pem',
key => 'etc/clientkey.pem',
password => $pass,
trusted => 'etc/trusted/51b63f6c.0'
);
if ( defined $agentclient->getError() ) {
die "Unable to connect:" . $agentclient->getError();
}
# check agent is available
print $agentclient->ping('hello agent'), "\n";
# get the Inca configuration
print $agentclient->getConfig(), "\n"; |
Place the code in a file called inca-test-agent within the $INCA_DIST/bin directory and replace all of the highlighted areas with values appropriate to your installation. To run the program, you will need to provide the path to the Inca Perl APIs which reside in $INCA_DIST/lib/perl. One choice is to execute the following:
env PERL5LIB=$PREFIX/lib/perl perl bin/inca-test-agent |
Type in the password provided to you by your Inca administrator when prompted. You should see something like this:
hello agent
<inca:inca xmlns:inca="http://inca.sdsc.edu/dataModel/inca_2.0">
<repositories>
<repository>http://inca.sdsc.edu/repository/latest</repository>
</repositories>
<resourceConfig>
<resources>
<resource>
<name>defaultGrid</name>
<xpath>//resource[matches(name, "localSite")]</xpath>
<macros>
...
</resources>
</resourceConfig>
<suites>
<suite>
<seriesConfigs>
<seriesConfig>
<series>
<name>cluster.math.atlas.version</name>
<uri>http:// ... cluster.math.atlas.version</uri>
<args>
<arg>
<name>cc</name>
<value>cc</value>
</arg>
<arg>
<name>dir</name>
<value/></arg>
<arg>
<name>help</name>
<value>no</value>
</arg>
<arg>
<name>log</name>
<value>3</value>
</arg>
<arg>
<name>verbose</name>
<value>1</value>
</arg>
...
<action>add</action>
</seriesConfig>
</seriesConfigs>
<name>sampleSuite</name>
<guid>incas://rocks-101.sdsc.edu:6323/sampleSuite</guid>
<description/>
<version>1</version>
</suite>
</suites>
</inca:inca> |
Alternatively, you can leverage the inca script to set the path for you. It looks for scripts that begin with inca- in the bin such as inca-some-command. Then you can invoke your script by typing ./sbin/inca someCommand which will automatically set the PERL5LIB for you. To execute the inca-test-agent script, type the following:
% cd $PREFIX; ./sbin/inca testAgent -P stdin:pass |
Type in the password provided to you by your Inca administrator when prompted. You should see the output as above.
7.2.3.2. Inca Java Client APIs
The Java Client API can be accessed on the Inca server at $INCA_DIST/lib/inca-common.jar or by downloading the inca-common tar ball, inca-common-java-bin.tar.gz. To install inca-common-java-bin.tar.gz in a directory called $PREFIX, perform the following steps.
Untar the inca-common-java-bin.tar.gz file
% mkdir $PREFIX; tar -C $PREFIX -zxvf inca-common-java-bin.tar.gz
Copy the credentials from your Inca administrator over to the new installation. The file trusted.0 will actually be the hash of the CA certificate and will look something like 51b63f6c.0.
% mkdir $PREFIX/etc; mkdir $PREFIX/etc/trusted % cp clientcert.pem $PREFIX/etc % cp clientkey.pem $PREFIX/etc % cp trusted.0 $PREFIX/etc/trusted
Below is a sample of code using the Java APIs that pings the Agent and queries for its configuration.
import edu.sdsc.inca.AgentClient;
public class AgentClientTest {
public static void main(String args[]) {
AgentClient agentClient = new AgentClient();
agentClient.setServer("rocks-101.sdsc.edu", 6323);
agentClient.setCertificatePath("clientcert.pem");
agentClient.setKeyPath("clientkey.pem");
agentClient.setTrustedPath("trusted");
System.out.print( "Please enter a password: " );
try {
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String password = br.readLine();
agentClient.setPassword(password);
} catch ( IOException e ) {
System.err.println( "Problems reading password" );
e.printStackTrace();
}
try {
agentClient.connect();
System.out.println( agentClient.commandPing("hello agent") );
System.out.println( agentClient.getConfig() );
} catch ( Exception e ) {
System.err.println( "Connection error to agent" );
e.printStackTrace();
}
}
} |
Place the code in a file called AgentClientTest.java within the $INCA_DIST directory and replace all of the highlighted areas with values appropriate to your installation. Note that the API looks for certificate files in the classpath so just the name of the file needs to be specified rather than a complete path. First set your classpath to include the jars in $INCA_DIST/lib as below:
% setenv CLASSPATH `perl -e "print join(':',glob('lib/*'))"`
or
% export CLASSPATH=`perl -e "print join(':',glob('lib/*'))"` |
Then compile the program as below:
% javac AgentClientTest.java |
This will create the file AgentClientTest.class. To run the program, you will also need to specify the directory where your credentials reside (specified below as etc), the etc/common directory, and . where the AgentClientTest.class resides. Execute as follows:
% java -cp .:etc:etc/common:$CLASSPATH AgentClientTest |
Type in the password provided to you by your Inca administrator when prompted. You should see something like this:
hello agent
<inca:inca xmlns:inca="http://inca.sdsc.edu/dataModel/inca_2.0">
<repositories>
<repository>http://inca.sdsc.edu/repository/latest</repository>
</repositories>
<resourceConfig>
<resources>
<resource>
<name>defaultGrid</name>
<xpath>//resource[matches(name, "localSite")]</xpath>
<macros>
...
</resources>
</resourceConfig>
<suites>
<suite>
<seriesConfigs>
<seriesConfig>
<series>
<name>cluster.math.atlas.version</name>
<uri>http:// ... cluster.math.atlas.version</uri>
<args>
<arg>
<name>cc</name>
<value>cc</value>
</arg>
<arg>
<name>dir</name>
<value/></arg>
<arg>
<name>help</name>
<value>no</value>
</arg>
<arg>
<name>log</name>
<value>3</value>
</arg>
<arg>
<name>verbose</name>
<value>1</value>
</arg>
...
<action>add</action>
</seriesConfig>
</seriesConfigs>
<name>sampleSuite</name>
<guid>incas://rocks-101.sdsc.edu:6323/sampleSuite</guid>
<description/>
<version>1</version>
</suite>
</suites>
</inca:inca> |