Note

The Grid Community Toolkit documentation was taken from the Globus Toolkit 6.0 documentation. As a result, there may be inaccuracies and outdated information. Please report any problems to the Grid Community Forums as GitHub issues.

GCTGRAM 5 → GT 6.0 Release Notes: GRAM5

Component Overview

The Grid Resource Allocation and Management (GRAM5) component is used to locate, submit, monitor, and cancel jobs on Grid computing resources. GRAM5 is not a Local Resource Manager, but rather a set of services and clients for communicating with a range of different batch/cluster job schedulers using a common protocol. GRAM5 is meant to address a range of jobs where reliable operation, stateful monitoring, credential management, and file staging are important.

Feature summary

New Features new since 5.2:

  • Bug fixes and improved testing

Other Standard Supported Features

  • Remote job execution and management

  • Uniform and flexible interface to local resource managers, including Condor, LSF, and SLURM, and GridEngine

  • File staging before and after job execution

  • File and directory clean up after job termination

  • Service auditing for each submitted

Removed Features

  • None.

Summary of Changes in GRAM5

New Features: GRAM5

*

Improvements: GRAM5

None.

Fixed Bugs for GRAM5

  • Fix crash when USER environment variable is not set

  • Incorrect argument order in globus_cond_wait() in globus-scheduler-event-generator package

Known Problems in GRAM5

  • GT-45: Manager lock double-locked

  • GT-47: globus-job-manager null pointer dereference for some call paths

  • GT-52: SEG may deadlock with threads

  • GT-56: Tear-down of object requires multiple threads

  • GT-103: GRAM refresh credentials test sometimes fails because job terminates

  • GT-292: Service tags may not isolate services completely

  • GT-324: Behaviour of globus-job-status

  • GT-369: GRAM5 skips some SEG events for PBS batch system

  • GT-389: globusrun and globus-job-run don’t report job failures to user

  • GT-418: globus-gatekeeper leaves stale processes behind if port 2119 is probed

Technology dependencies

GRAM depends on the following GCT components: * Globus Common * GSI C * GridFTP server

Tested platforms

GRAM5 has been tested extensively on the following platforms:

Table 1. Tested Platforms
Operating System Distribution Version(s) Architecture(s)

Linux

CentOS

5, 6

i386, x86_64

7

x86_64

Fedora

20, 21, 22

i386, x86_64

Red Hat Enterprise Linux

5, 6

i386, x86_64

7

x86_64

Scientific Linux

5, 6

i386, x86_64

7

x86_64

SUSE Linux Enterprise Server

11SP3

x86_64

Debian

6, 7, 8

i386, amd64

Ubuntu

12.04LTS, 14.04LTS, 14.10, 15.04

i386, amd64

Mac OS X

10.6-10.10

i386, x86_64

Solaris

OmniOS

r151006

x86_64

Windows 7

Cygwin

i386, x86_64

MingW64

i386, x86_64

Backward compatibility summary

Protocol changes in GRAM since GT4 series:

  • The GRAM5 service uses a superset of the GRAM2 protocol for communciation between the client and service. The extensions supported in GRAM5 are implemented in such a way that they are ignored by GRAM2 services or clients. These extensions provide improved error messages and version detection.

  • GRAM5 does not support task coallocation using DUROC and its related protocols. Jobs submitted using DUROC directives will fail.

  • GRAM5 does not support file streaming. The standard output and standard error streams are sent after the job completes instead of during execution. As a special case, support for the Condor grid monitor program implements a small subset of the streaming capabilities of GRAM2 in GT 4.2.x.

Associated Standards

None

For More Information

See GRAM5 Documentation for more information about this component.