Call for Community Testing: 3.9.4 WS GRAM

What is a "Call for Community Testing"?

A Call for Community Testing is a mechanism to notify our users that new Globus code is available for testing in the field. Through these calls, the Globus Alliance hopes to expose its code to a wide variety of usage scenarios early in its development process. The ultimate goals are to catch bugs that have historically been found only after final releases, and to elicit feedback from the community on ways our software can be improved.

Participating in the WS GRAM Testing Call is easy!

  1. Optional: Consider sending mail to testing@globus.org to let us know that you're helping out and describing what you intend to test.
  2. Install the software in a non-production environment. Use the 3.9.4 distribution from http://www-unix.globus.org/toolkit/downloads/development/; the code can also be retrieved directly from CVS using the tag "globus_3_9_4".
  3. Exercise the software.
  4. Log your experiences in http://bugzilla.globus.org/globus/ under the "GRAM" product. Please mention 3.9.4 explicitly in the body of the report.
  5. Optional: Consider sending descriptions of your tests to testing@globus.org so that we might use them to build standard tests in the future.
  6. If you have any questions or comments about the process, send an email to testing@globus.org.
  7. If you have any questions or comments regarding this component, join the gt4-friends list to participate in discussions with other testers. (To subscribe, send an email to majordomo@globus.org containing the words "subscribe gt4-friends" in the message body.)

Testing period

The testing period for this call is December 17 - January 31 2005.

About WS GRAM

Web Services Grid Resource Allocation and Management (WS GRAM) component comprises a set of WSRF-compliant Web services to locate, submit, monitor, and cancel jobs on Grid computing resources. WS_GRAM is not a job scheduler, but rather a set of services and clients for communicating with a range of different local job schedulers using a common protocol. WS GRAM is meant to address a range of jobs where reliable operation, stateful monitoring, credential management, and file staging are important.

Reasons for testing WS GRAM

We need volunteers to stress test WS GRAM to make it more scalable and robust. Compute clusters, scheduler installation and configuration, applications executed vary greatly. It is difficult to test for the wide variety of environments that GRAM interfaces with. Your help in testing and reporting problems with your site is appreciated.

Technology dependencies

GRAM depends on the following GT components:

  • Java WS Core
  • Transport-Level Security
  • Delegation Service
  • RFT
  • GridFTP
  • MDS - internal libraries

GRAM depends on the following 3rd party software. The dependency exists only for the batch schedulers configured, thus making job submissions possible to the batch scheduling service:

  • PBS
  • Condor
  • LSF
  • other batch schedulers... (where the GRAM scheduler interface has been implemented)

Environment/build parameters and other special conditions to test

  1. Submit a burst of jobs. Many individual concurrent GRAM jobs.
  2. Submit a large number of long running jobs.
  3. Submit a variety of job descriptions, not just executable and arguments.