8/09/2006

Dividing and Conquering - CTSS V4

In the first instantiation of TeraGrid (nearly 5 years ago) we defined a set of software and services that would be run on all TeraGrid platforms. The purposes were to (a) provide users with a consistent experience on all TeraGrid systems and (b) integrate those systems with important functions such as single-signon, remote job submission, system-wide accounting, etc.

Affectionately named after the early Cray Time Sharing System (operating system), the Coordinated TeraGrid Software and Services (CTSS) v1 had many more components than was necessary, as we determined after users began to arrive, so CTSS v2 was more streamlined. A few months ago we moved to and even more streamlined CTSS v3 and we're still doing a post-mortem regarding how the transition went and how we can continue to improve on smooth evolution of the TeraGrid software environment. But the challenge of this software stack approach is moderate when you have a large number of resources, and significantly harder as those resources become more diverse.

As we have been developing plans for CTSS v4 we are evolving our approach. V4 will consist of a set of required core services (authorization, information services, verification and validation, and accounting/audit) along with an optional set of "kits" that provide specific functionality (workflow support, program development, job execution, etc.). Each TeraGrid resource provider will run the core components and will select the set of kits they will support on each of their systems. Some may elect only to support job execution and workflow. Others may also support the common program development environment. We are initially looking at a total of eight discrete kits, and these will be fleshed out over the next few months.

This approach moves us toward what I believe is an achievable, though challenging, goal. I'd like for CTSS V5 to be a set of service descriptions, leaving the implementation of those services at the discretion of the resource provider. Certainly we will continue to integrate and package software that can be used to implement TeraGrid CTSS, but the use of our implementations should not be necessary for a resource to interoperate within TeraGrid.

This is an approach that I think can work where resources reside in different Grid facilities as well. My view is that a science gateway user should be able to put together a workflow that harnesses resources in TeraGrid or other Grids, with the only key consideration being that the user is authorized to use those resources.

CTSS v4 will be an important move for the TeraGrid community, as the benefits to this modularization can only be harnessed by rigorous change management and a commitment to providing the tools that users and science gateway partners need in order to navigate resources with different combinations of services. We're starting with a careful evaluation of how the CTSS v3 transition has gone, and we will be engaging both resource providers and end users as we begin to specify the first set of kits.

If you're interested in helping out, pleaase contact Lee Liming, who is leading our CTSS v4 planning efforts.

Writing to you from...

2 Comments:

Blogger Lee Liming said...

This comment has been removed by a blog administrator.

8/14/2006 11:22:00 AM  
Blogger Lee Liming said...

Charlie, thanks for the description of our CTSS 4 strategy. Your explanation is right on.

Somewhat tangentially, the science gateway scenario that you mention is an interesting one, because it begs some questions about how we expect science gateways (especially those that are provisioned by TeraGrid resources) to be constructed and used. I see a couple of interesting questions. One is whether the gateway user is the person who defines the workflow or not. The other is whether it should matter that the user is authorized to use a resource or not.

I'm going to decline to write about the first question, but on the second point (authorization), I personally think that it would be much preferable for TeraGrid resources to be able to provision (provide resources to support) science gateways on a per-gateway basis rather than on a per-user basis. At the same time, I think there will be a demand for quality of service adjustments on a per-user basis.

For example, if a TeraGrid resource provider decides to support a particular gateway, then anyone who's a registered user of that gateway should be able to use that gateway--with the resource providing cycles or storage or whatever in support of that use--without the resource "recognizing" the end user at all. At the same time, when certain people use the gateway, their workload could be blocked from using the resource or given preferential treatment (higher priority) because the system does, in a few cases, recognize them. In this case, whether the user is authorized or not isn't the question. The question is whether or not the gateway is authorized and how the identity of the user might modify that basic authorization.

For this scenario to be possible, the authentication between gateway and resource has to include both the user's identity and the gateway's identity. The authorization decision on the resource can then take both identities into consideration. This is a fairly simple example of attribute-based authorization, and there are a number of relatively new tools that can be used to implement the capability.

In fact, this scenario is being prototyped this summer by a graduate student at Purdue University working under Sebastien Goasguen. The premise is to try using GridShib and VOMS (two of the before-mentioned tools that also provide support for Grid identity authentication) to provide this attribute-based authorization capability for the NanoHUB science gateway.

I expect that this kind of scenario will also show up at our authorization workshop this month. Eventually, the capability to support this scenario should become one of those provided by CTSS's "TeraGrid Core" kit.

8/14/2006 11:30:00 AM  

Post a Comment

<< Home