This document is a work-in-progress and applies to this development release. The latest drafts of docs can be found in the Development Documentation directory. You are strongly encouraged to file bugs for both the development documentation and software on our Bugzilla page. We appreciate your participation.
Call for Community Testing: 3.9.3 RLS
- What is a "Call for Community Testing"?
- Participating in the RLS testing call
- About RLS
- Reasons for testing RLS
- Technology dependencies
- Environment/build parameters and other special conditions to test
- Release notes
What is a "Call for Community Testing"?
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, the Globus Alliance hopes to expose its 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.
Participating in the RLS Testing Call is easy!
- Optional: Consider sending mail to testing@globus.org to let us know that you're helping out and describing what you intend to test.
- Install the software in a non-production environment. Use the 3.9.3 distribution from http://www-unix.globus.org/toolkit/downloads/development/; the code can also be retrieved directly from CVS using the tag [tag].
- Exercise the software.
- Log your experiences in http://bugzilla.globus.org/globus/ under the "Replication Services" product "RLS" component. Please mention 3.9.3 explicitly in the body of the report.
- Optional: Consider sending descriptions of your tests to testing@globus.org so that we might use them to build standard tests in the future.
- If you have any questions are comments about the process, send an email to testing@globus.org.
Testing period
The testing period for this call is [date range].
About RLS
The Replica Location Service (RLS) allows the registration and discovery of replicas. An RLS maintains and provides access to mapping information 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.
Reasons for testing RLS
RLS is available for a variety platforms (Linux, UNIX flavors). We can only maintain a small number of possible platforms and most of our work takes place on RedHat Linux 7 and 9 and with MySQL server for database management. In addition, the distributed nature of RLS, and the wide array of use cases that can be satisfied with it, make it difficult to simulate the many production configurations that exist for the RLS.
Technology dependencies
RLS depends on the following GT components:
- XIO
RLS depends on the following 3rd party software:
- Relational Database Management System (RDBMS) including MySQL or PostgreSQL
- iODBC
- ODBC driver including MyODBC or psqlODBC
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 PostgreSQL and 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 propogate to connected RLIs.
- Test large-scale deployment using C Client API to execute 1000's of bulk operations per second.
Release notes
Release notes for the 3.9.3 RLS can be found here.
