gLite Middleware

1. Release Description

This release contains the gLite Middleware v. 1.3 (1.3.0). The following sections provide additional information about the release content, the module dependencies and known issues. The gLite Middleware is a suite of several gLite Services and clients. Please refer to the individual gLite Services and Clients release notes for additional information. For information about installing and using the gLite Middleware, please refer to the gLite Installation and User Guides.

2. Changes in this release

This release is the General Availability (GA) gLite v 1.3.

In this release the following major changes are included:

• New FTA including architecture refactoring: now the FTA is logically split in two agents: the Channel Agent and the VO Agent, in order to allow proper inter-VO scheduling. This change also affects the configuration.
• New separate modules to install the File Placement Service (FPS)
• Several bug fixes and improvements to R-GMA Server and Client
• Several bug fixes and improvements to Computing Element.
• The FPS client has been added to the User Interface (UI) and to the Worker Node (WN)

3. Release contents

The gLite Middleware v. 1.3 is composed of the following gLite modules:

Module name	Version	File
gLite Computing Element	2.0.2	../../../../../../glite-web/egee/packages/R1.3/RR20050715/installers/glite-ce_installer.sh
gLite File Transfer Service	2.1.0	../../../../../../glite-web/egee/packages/R1.3/RR20050715/installers/glite-data-local-transfer-service_installer.sh
gLite Data Transfer Agents	1.1.0	../../../../../../glite-web/egee/packages/R1.3/R20050805/installers/glite-data-transfer-agents-oracle_installer.sh
gLite File Placement Service	2.1.1	../../../../../../glite-web/egee/packages/R1.3/R20050805/installers/glite-file-placement-service-oracle_installer.sh
gLite R-GMA Client	5.0.0	../../../../../../glite-web/egee/packages/R1.3/RR20050715/installers/glite-rgma-client_installer.sh
gLite R-GMA Server	5.0.0	../../../../../../glite-web/egee/packages/R1.3/RR20050715/installers/glite-rgma-server_installer.sh
gLite R-GMA Service Publisher	5.0.0	../../../../../../glite-web/egee/packages/R1.3/RR20050715/installers/glite-rgma-servicetool_installer.sh
gLite Security Utilities	1.0.3	../../../../../../glite-web/egee/packages/R1.3/RR20050715/installers/glite-security-utils_installer.sh
gLite Service Discovery	1.0.0	../../../../../../glite-web/egee/packages/R1.3/RR20050715/installers/glite-service-discovery_installer.sh
gLite Standard Worker Node	2.1.0	../../../../../../glite-web/egee/packages/R1.3/RR20050715/installers/glite-wn_installer.sh
gLite User Interface	1.1.0	../../../../../../glite-web/egee/packages/R1.3/RR20050715/installers/glite-ui_installer.sh

4. Prerequisite and Dependencies

The gLite modules have a number of pre-requisites. All information can be found on the individual modules release notes and the gLite Installation Guide.

For a list of the external dependencies, please refer to the individual gLite Service and Clients release notes.

5. Known issues

The known issues with each module in this release are detailed in the individual release notes. The most important issues are:

• The interface of FTS/FPS has been changed in a non backward compatible way, which means one has to replace the clients, if wants to use the new services.
• The Information System currently used by the Workload Management System is not RGMA, given that the integration between these two components is not yet available. In the next future the provisioning of the WMS RGMA purchaser will allow the full exploitation of RGMA. At this stage, however, WMS is making use of a fake BD-II, where information is filled in by non automated procedures (instead of information providers), and there is no dynamic information available.

BD-II is a well known component of existing GRID middleware (e.g. LCG). Please, consult LCG guides for documentation on how to install and configure the BD-II.

BD-II is required if the gLite WMS needs to be configured in "push mode", where the information on available resources is taken from the BD-II  and shipped to the WMS Information Cache by the LDAP purchaser. Other modes of operation for the information flow (synchronous and asynchronous pull mode), do no strictly require the usage of the BD-II.

If WMS is used in push mode, all the CE information has to be filled in according to the current used Glue Schema inside it.

For this reason the current deployment module foresees the insertion of the BD-II contact hostname, port and base DN as optional parameters.

Another case in which the BD-II is mandatory is when users want to make use of InputData-driven match making.

If a user in fact uses the InputData filed and its associated StorageIndex contact in the JDL file, then all available Storage Element information goes in the BD-II to allow matching.

• Currently jobs get a full proxy rather than a restricted one as done in LCG. This is needed for multi-hop submission (as e.g. to condor pools but also eventually for CE – CE submission) and apparently GT4 abandoned support for restricted proxies. Security implications need to be better understood. Currently being discussed in the MWSCG.
• If multiple R-GMA archivers are used, the content is sometimes inconsistent. The problem is under investigation
• gLite I/O and gLite FTS security models conflict. The update of the architecture document (DJRA1.4) contains a first description of the plan. The issue is being actively discussed
• Oracle Fireman sometimes timeouts with large number of clients. So far it has been only randomly reproduced. It may be related to a race-condition in axis
• glite put/get fails while putting files bigger than 2 Gb
• VOMS Admin produces internal database inconsistency faults on getGridmapUsers (used by the mkgridmap script to fill the grid-mapfile) under certain conditions involving users registered twice with the same certificate subject, but different CA keys

• In the User Interface if the /etc/grid-mapdir/vomsdir directory (or an alternative directory specified by the X509_VOMS_DIR environment variable) exists, but it’s empty, the FTS clients fail with a segmentation fault. In any case that directory should not be empty for VOMS to work, but it must contain the public certificates of all required VOMS servers
• No removal procedure is provided with this release apart from the removal of the RPMS. Any account, group or other resource created during the module configuration must be manually cleaned. In addition, if several gLite modules are installed on the same node, the removal procedure may fail if there are overlapping dependencies. This will be fixed in a future release. As a workaround all gLite RPMS can be removed with the following command:

rpm –e `rpm –qa | grep glite-`

• The UI module has complex external dependencies. Using the installer script is recommended only on clean machines with standard configuration. If alternative versions of the external dependencies have to be used, please customize the installer scripts as necessary or use a more sophisticated RPM management system. For non root installation, the installer script is for the time being the only supported method

6. Issues closed since last release

For a list of the closed bugs and issues, please refer to the individual gLite Services and Clients release notes.

7. Licensing

All gLite code is open source and developed as part of the EU-funded EGEE project. For more information on the licence and copyright statements, please refer to the EGEE web site. The licence can be found at http://public.eu-egee.org/license/license2.html .