TeraGrid Client Software - Requirements
From TeraGrid Wiki
The information on this page is intended to serve as our documentation of the requirements for the TeraGrid Client Software activity. This page provides an understanding of what we are trying to accomplish/enable through this work. It is a living document: details will be filled in as our work progresses.
Contents |
Charter
From the GIG's Y3 program plan:
Coordinating with TeraGrid's campus outreach program, the GIG's software integration staff will design and produce a software distribution that provides client-side integration with TeraGrid's key service interfaces. This software distribution will be aimed at institutions that make use of TeraGrid resources and will offer these institutions the ability to pre-load software locally that eases expanding their local computing environment to include TG resources.
We will design and produce a software distribution that provides client-side integration with TeraGrid's key service interfaces. This software distribution will be aimed at institutions that make use of TeraGrid resources and will offer these institutions the ability to pre-load software locally that eases expanding their local computing environment to include TG resources. Examples: remote login clients, data movement clients, remote job submission tools. The mechanisms employed in the software distribution should match with the mechanisms provided by TeraGrid's CTSS capabilities, and the requirements (usability, documentation, packaging, platform support) will be identified in coordination with TeraGrid's campus outreach program.
User Targets
- University/College IT Administrators
- University/College HPC Users
TeraGrid's Education/Outreach/Training (EOT) team, led by Scott Lathrup, will be an invaluable source of contacts and activities to figure out the goals and requirements for the above two target groups.
In addition to the above targets, we should be mindful of the possibility that other TeraGrid areas and teams may find this software distribution useful. For example, the user services team might find it helpful to be able to offer this to users who want to load TG client software locally. Or, the science gateways team might find it helpful to include this in the set of tools offered to prospective gateway development teams. If we can leverage this activity further, that would be good, but they must not distract from the primary goal, which is to provide something useful for campuses.
Goals
The following were our initial candidates for high-level goals. Collaboration with TG's campus partnerships effort and specific campuses was arranged to decide which of these we should be aiming for.
- Campus IT administrators can pre-load TeraGrid client software on lab workstations, staff systems, and department/campus servers in order to make it easier for any TG users on the campus to use TG once they have an allocation.
- Campus IT administrators can implement TeraGrid capabiliites (e.g., CTSS) on their own systems and train their users to use them so that if/when users get TG allocations, TG looks the same to them as the campus systems they were using all along.
- Campus IT users can easily install TG client software on their own systems in order to more easily use TG once they have an allocation.
- Campus IT users can easily install middleware tools that allow their applications to (more) seamlessly use both campus and TG resources.
Out of these initial thoughts, a document was prepared for presentation to the EOT Team. Three potential directions were presented:
Option 1 - A distribution of clients to TeraGrid services that campus IT groups could make available to their users, or that campus users could use directly.
Option 2 - A distribution of higher-level software that can interface both with campus resources and with TeraGrid resources. This could be targeted at application developers that are interested in making the transition between campus and TeraGrid resources as smooth as possible.
Option 3 - A software distribution consisting of CTSS-like services that could be installed on-campus. This would allow campuses to make their resources appear like TeraGrid resources. Benfits would include the utility of the services themselves and ease of transition to the TeraGrid for campus researchers.
Further discussion led to the decision to focus on either Option 1 or Option 2, since Option 3, while potentially useful, doesn't really fit under the realm of providing client software.
A discussion with Jay Boisseau and Ed Walker of TACC yielded some progress in terms of the plan moving forward. This was initiated since Jay had in the past expressed interest in having a TG client toolkit available (like in Option 1) and MyCluster (developed by Ed) seems like it would be potentially useful in persuing Option 2. The important results of the discussion were:
- MyCluster does in fact have the potential to provide the backbone for Option 2. It currently is not available as a download for general use, but it is headed in that direction. Work toward Option 2 should hold off until Ed has something he can hand off to us for prototyping.
- The two options are not mutually exclusive. In fact, it may be the case that Option 2 will require a good deal of the functionality provided by Option 1.
Thus, it was decided that the plan moving forward would involve focusing on Option 1 for the short-term, making sure to keep work on Option 2 as a goal in the medium-term. Initial work should focus on improving the issues found in working on the preliminary protoype.
The two phases that have been defined for the project are operating under the titles "Basic Client Toolkit" and "Scale-Up Client Toolkit".
Use Scenarios: Basic Client Toolkit
The following use scenarios illustrate the function of the initial component of this project: the Basic Client Toolkit. Use scenarios for the Scale-Up Client Toolkit will be added when its design is more fully considered.
Installing
Before use, the toolkit must be installed. The person executing the installation procedure may be a researcher looking to access TeraGrid from a local resource, or a campus IT administrator making TeraGrid client tools available to their users. Ideally, the installation procedure will be well-suited to either of these types of users. In order for this to be true, the install should be as user-friendly as possible. Specific goals include minimizing the number of steps involved and also the number of potentially confusing questions that need to be answered at install time. In addition, output from any installation scripts should be terse and understandable. The installation also should complete relatively quickly and should not occupy an unreasonable amount of disk space.
Single Sign-On
Users of the toolkit will be able to access TeraGrid's single sign-on mechanism after installation. A single command is run and provided with the user's login name and password. Form then on, the toolkit's other capabilities can be leveraged without further need for authentication.
Remote Login
The toolkit will enable users to easily login to TeraGrid resources. For details on the types of operations supported, see the use cases outlined in CTSS 4 Remote Login Capability Kit.
Job Submission
The toolkit will enable users to submit jobs for execution on TeraGrid resources. A job can be submitted directly from the system where the toolkit is installed; there is no need to first login to a TeraGrid system. See CTSS 4 Remote Compute Capability for detailed usage scenarios.
Data Movement
Data movement operations will be made available by the toolkit. This includes the ability to move data between the local system and TeraGrid resources, or between separate TeraGrid sites. Detailed usage scenarios for data movement are given in CTSS 4 Data Movement Implementation.
Uninstalling
If a user decides they no longer need the toolkit, it should be able to be easily and completely removed from the system.
