Software Links
Getting Started
- Doc Structure
- A Globus Primer
- Quickstart
- Installing GT
- Platform Notes
- Migrating from GT2
- Migrating from GT3
Reference
- PDF version
- Best Practices
- Coding Guidelines
- API docs
- Public Interfaces
- Resource Properties
- Samples
- Glossary
- Index
- Performance Studies
Common Runtime
Security
Data Mgt
Information Svcs
Execution Mgt
Table of Contents
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 batch/cluster 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.
New features since 4.0.2
globus-job-*-ws command line tools included in release
- Out-of-the-box support: no more dowloading of development packages required for globus-job-run-ws, globus-job-submit-ws, globus-job-get-output-ws, globus-job-clean-ws.
Database-based persistence.
- all persistence data is stored in a database
- an embedded Derby database is setup by default
- PostgreSQL 7.2 and 8.0 currently supported as alternatives to Derby
Job description extensions.
- specify elements beneath <extensions>
- Use <multiAuthSubject> to specify a credential subject for a multijob to use when authorizing subjob hosts.
- Out-of-the-box support: no more dowloading of development packages required.
- Use <condorsubmit> to specify arbitrary Condor directives.
- Use <shouldTransferFiles>, <whenToTransferOutput>, <transferInputFiles>, and <transferOutputFiles> to specify the similarly-named Condor directives.
- Use <nodes> directly or <resourceAllocationGroup> to specify PBS node requirements (i.e. translated to #PBS -l nodes=..." directive).
SoftEnv support.
- Configure the service whether to use your .soft file on the compute node or not by default (Fork, PBS, and LSF only).
- Add <softenv> extension elements to specify explicit SoftEnv statements that override the lines in your .soft configuration file (Fork, PBS, and LSF only).
Independent resource manager adapter API.
- Create your own RM adapter implementation. For example, if a resource manager has a java API for submitting and monitoring jobs, a new java only RM adapter could be written and used inplace of the GT provided Perl-based RM adapter. A Windoows based GRAM service implementation would be easier / more straight forward.
- Use our GT Perl-based RM adapter and SEG monitoring in your own service.
Removed unnecessary depedency of WS GRAM on Pre-WS GRAM jobmanager package.
- Separated out Perl modules into their own globus_gram_job_manager_scripts package.
The following changes have occurred for WS GRAM since the last stable release, 4.0.2:
Interface changes.
- No interface changes have occured strictly speaking, although support for certain job description extensions has been added.
Stability improvements.
- Out-of-memory errors in the service have been drastically reduced if not eliminated by forcing all external events through the state machine.
Performance improvements.
- No documentable performance improvements have been made.
- Bug 4174:GRAM should check for needed Perl modules
- Bug 4154:a few gram scheduler tests from the trunk are broken
- Bug 4034:globusrun-ws's '-s' option doesn't like IPs
- Bug 3775:4.2,"CAMPAIGN: Investigate job info from schedulers
- Bug 4211:Sf and -Tf options not working for multi jobs
- Bug 4312:WS GRAM resourceAllocationGroup bug
- Bug 4390:PBS SEG can't open log of the 1st day of the month
- Bug 4445:Incorrect perl packages in globus_wsrf_gram_scheduler_test
- Bug 4376:Multijob shouldn't be distributing credential endpoints to subjobs
- Bug 3778:WS-GRAM dependant on GT2 job manager
- Bug 4475:Default jobType=multiple encoded as unknown job type in usage packet
- Bug 1562:Condor jobs fail when running globus-sh-exec job
- Bug 2049:Batch providers need a namespace
- Bug 3575:SEG dependent on GLOBUS_LOCATION env var
- Bug 2527:Add a failure case for non-existant queue to scheduler test suite
- Bug 3495:queue information, job count not reported to MDS
- Bug 3726:GlobusRun error message typo
- Bug 3803:Default scratchDirectory doesn't exist
- Bug 3384:Inconsistent jobType/count parameter semantics
- Bug 3672:Streaming with PBS fails
- Bug 3746:bad link on scheduler tutorial
- Bug 3675:wsrf gram client file streaming error
- Bug 4153:gram scheduler test failing - submit202
- Bug 4178:no job output when streaming with globusrun-ws
- Bug 4191:globusrun-ws job submission hangs
- Bug 3910:Bad permissions on condor log file prevents job submissions
- Bug 3529:setup/postinstall fatal errors should be warnings
- Bug 4216:Empty submit_test/submitxxx.err causes FAILure in Local tests
- Bug 4308:globusrun-ws handles -self differently than java clients
- Bug 3948:Service must release all of its resources on deactivation
- Bug 4356:globusrun-ws is overriding manual subjob credential delegations
- Bug 4275:globus-gram-local-proxy-tool fails on Solaris
- Bug 4430:staging was failed on globusrun-ws.
- Bug 4452:job submission response is effected by java 1.5 thread processing
- Bug 4464:setting the mpirun/exec path used for mpi jobs
- Bug 4474:globus-gridmap-and-execute problem with additional PDPs
- Bug 2286:internationalization
- Bug 4431:freeze by Unsubmitted on personal WS GRAM
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:
Scheduler adapters. These dependencies exist only for the batch schedulers configured, thus making job submissions possible to the batch scheduling service. Scheduler adapters are included in the GT 4.1.0.x releases for the following schedulers:
Other scheduler adapters available for GT 4.1.0.x releases:
- SGE scheduler adapter interface
- IBM LoadLeveler (As of release 3.3.1). For more information see "What's new" in the LoadLeveler product documentation
- other batch schedulers... (where the GRAM scheduler interface has been implemented)
The XML::Parser Perl module is required for job description extension support.
Tested platforms for WS GRAM:
Linux
- Fedora Core 1 i686
- Fedora Core 3 i686
- Fedora Core 3 yup xeon
- RedHat 7.3 i686
- RedHat 9 x86
- Debian Sarge x86
- Debian 3.1 i686
Tested containers for WS GRAM:
- Java WS Core container
- Tomcat 4.1.31
Protocol changes since GT version 4.0.2:
- None. WS GRAM in 4.1.0 is interoperable with 4.0.x
See WS GRAM for more information about this component.