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, we hope to expose the 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.

2. Participating in the RLS Testing Call is easy!

Install the software in a non-production environment. Use the 4.1.1 distribution from http://www.globus.org/toolkit/downloads/development/; the code can also be retrieved directly from CVS using the tag globus_4_1_1.
Exercise the software.
Log your experiences in http://bugzilla.globus.org/globus/ under the "Replica Location" product "RLS" component. Please mention 4.1.1 explicitly in the body of the report.
If you have any questions or comments regarding this component, join the rls-user@globus.org list to participate in discussions with other testers. (To subscribe, read the instructions here.)
Optional: Consider sending descriptions of your tests to rls-dev@globus.org so that we might use them to build standard tests in the future. (To subscribe, read the instructions here.)

2.1. Testing period

The testing period for this call is [FIXME: date range].

3. About RLS

The Replica Location Service (RLS) is a standalone server (i.e., it is not deployed in a Web services container) that provides for the registration and lookup of replica information. Within the RLS, there are two types of services, a catalog service and an index service.

The Local Replica Catalog (LRC) maintains a catalog of replica information. Replica information in the RLS is maintained in the form of mappings from logical names for data items to target names. These target names may represent physical locations of data items, or an entry in the RLS may map to another level of logical naming for the data item.

In addition to the LRC, the RLS also exposes the Replica Location Index (RLI). The RLI maintains an index of logical names which indicates the LRC services(s) that have mappings for the specific logical names. The LRC generates an index of its logical names and pushes the index to one or more RLI services.

In a typical deployment, the RLS will be deployed in conjunction with one or more Storage Elements (SE). The LRC will be used to store mappings from logical names for data sets to the physical file locations as managed by the SEs. The LRC then sends an index of its contents to its associated RLI service as well as multiple remote RLI services at collaborating sites. Clients interested in a particular logical name will first query a RLI service to find the LRC services, then they will query one or more LRC services to find the target names (which may correspond to storage location URLs).

4. Reasons for testing RLS

We need volunteers to exercise RLS to... [FIXME]

5. Technology dependencies

RLS depends on the following GT components:

globus_core
globus_common
globus_io
globus_gssapi_gsi
globus_usage

RLS depends on the following 3rd party software:

RDBMS: MySQL, PostgreSQL, or Oracle
ODBC manager: unixODBC, iODBC
ODBC driver: MyODBC, psqlODBC, or Oracle

6. Environment/build parameters and other special conditions to test

Build, install, and test on RedHat (ES, AS), Fedora, and Debian flavors of Linux.
Build, install, and test on FreeBSD, Solaris, AIX, and HP-UX flavors of UNIX.
Build and test Java clients using JDK 1.4 compliant JVM's from vendors other than Sun (e.g., IBM).
Deploy with Oracle for database management.
Test large-scale deployment with multiple sites for LRC and RLI services in fully connected and partially connected architectures.
Test large-scale deployment by registering several million logical and physical file names at each LRC and propagate to connected RLIs.
Test large-scale deployment using C Client API to execute 1000's of bulk operations per second.

Prev	Up	Next
globus-rls-server	Home	Part . GT 4.1.1 WS Replica Location Service (WS RLS)