GridWay 4.7 Release Notes (released on February 24, 2006)

In GridWay 4.0, we introduced an architecture for the execution manager module based on a MAD (Middleware Access Driver) to interface Grid execution services. In this release we t ake advantage of this architecture to implement an information manager module with a MAD that interfaces Grid information services, and a transfer manager module with a MAD that i nterfaces Grid data services. Moreover, we will decouple the scheduling process from the dispatch manager through the use of a external and selectable scheduler module. We expect some application performance gains with this new architecture.

End-user benefits:

1. No configuration needed to interface Grid Information Systems, GridWay 5.0 will be shipped with drivers to interface: MDS2, MDS2 (Glue-schema), MDS4, and static host list file (Round-robin).
2. Resource Selection based on common resource attributes. The user no longer need to specify an LDAP or XPath filter, but a set of boolean expressions, function of the resource properties.
3. Resources will be ranked using a mathematical expression, function of the resource properties. We will no longer support ad hoc programs to rank resources.
4. A new command will be added, gwhosts, that will show the resources available in the testbed, this command will mainly make used of the underlying information system driver for debugging purposes.
5. We expect some performance improvements since the overhead induced by the information retrieval overhead will be drastically reduced. This new brokering system will also allow to overlap the preparation (prolog stage) and termination (epilog stage) of two jobs submitted to the same host.
6. With the new Middleware Drivers, Prolog and Epilog stages no longer need to be executed through the GRAM service, so we expect an important improvement in the preparation and termination times.

Some efforts are being made to make variable notation more consistent in GridWay configuration files, also GridWay 4.7 will:

1. Simplify job-template contents. Although we will support per-job configuration of scheduling, and module variables, configuration parameters will be used by default ($GW_L OCATION/etc/job_template.default).
2. Check Job template syntax.
3. Resource properties and expressions will follow intuitive semantics, e.g. REQUIREMENTS = (CPU_MHZ > 1800) & (ARCH = “i686”).

GridWay 4.0 includes a functional subset of the Distributed Resource Management Application API. In this release we will include full support to the current standard, some new fe atures will be added to GridWay:

1. New HOLD and RELEASE states. Jobs can arrive the HOLD state when submitted.
2. JAVA binding implementation.
3. GridWay will also execute the standard DRMAA test-suite.

The previous release of GridWay supports job migration when a performance degradation is detected. However, this feature was not documented. In this new release you will find.

1. Jobs will be equipped with a light-weight self monitoring system (through the wrapper module, there is no need to modify user applications). The job will be migrated when it i s no receiving as much CPU as you expected.
2. Check-points will be periodically retrieved to the client machine or a checkpoint server defined by the user.

Manual pages for client tools have been updated. Also client tools are being modified to support the new features described above.