December 2004 - ogsa-wg - lists.ogf.org

Dial-in number for today's f2f session...
by Jem Treadwell 09 Dec '04

09 Dec '04

... is 1-800-480-3702 id 778485# Thanks, - Jem -- Jem Treadwell Hewlett-Packard Company Phone: (732) 577-6043 200 Route 9 North Fax: (732) 577-6003 Manalapan, NJ 07726 E-mail: Jem.Treadwell(a)hp.com

1 0

Re: [ogsa-wg] Start tomorrow @ 8am
by Susan Malaika 09 Dec '04

09 Dec '04

When can we call in to get an update? (The callin number says it is restricted at this time) Susan Malaika

1 0

FW: gf-chairs GGF13 News
by Hiro Kishimoto 09 Dec '04

09 Dec '04

Hi all, GGF asks us about our plan for GGF13. Let's put it into F2F meeting agenda and write up initial plan on Friday or Thursday. Thanks, ---- Hiro Kishimoto

1 0

PURSE
by Ian Foster 09 Dec '04

09 Dec '04

I was also asked for information about PURSE (portal based user registration service) today, here is a doc that has some details. Ian.

1 0

Start tomorrow @ 8am
by Ian Foster 09 Dec '04

09 Dec '04

Hiro asks me to remind us all that we start tomorrow at 8am. Ian. _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org

1 0

Glossary working draft
by Jem Treadwell 09 Dec '04

09 Dec '04

Hi, as promised at today's f2f session, here's the current working draft of the OGSA V1 Glossary. I think I have all of the changes agreed so far incorporated, although I still have to make a final check. There are a couple of highlighted areas where the final wording has yet to be agreed, and I'm still waiting for input on a couple of other areas. I also have yet to respond to the comments. Once all changes are made I'll provide a copy for final review. If you have any comments, please let me know, but bear in mind that these changes are being made for v1, and in response to the comments received during the public comment period. Changes outside that scope will need to be made for v2; any input for that is welcome. Thanks, - Jem -- Jem Treadwell Hewlett-Packard Company Phone: (732) 577-6043 200 Route 9 North Fax: (732) 577-6003 Manalapan, NJ 07726 E-mail: Jem.Treadwell(a)hp.com

1 0

JSDL spec and schema links
by Andreas Savva 08 Dec '04

08 Dec '04

For those who expressed interest to have a look at the JSDL specification: https://forge.gridforum.org/projects/jsdl-wg/document/draft-ggf-jsdl-spec/en /11 and the schema https://forge.gridforum.org/projects/jsdl-wg/document/jsdl.xsd/en/3 The schema and the spec may be slightly out of sync. (The schema included in the spec is one step behind what's on gridforge.) Comments welcome. -- Andreas Savva Fujitsu Laboratories Ltd

1 0

Defining the Open Grid Services Architecture
by Hiro Kishimoto 07 Dec '04

07 Dec '04

Hi all, The attached document is intended to provide a basis for further discussing on some important issues within the OGSA document. The session is planed to hold Thursday morning. OGSA-WG co-chairs, ADs, and GGF chair have written down it. However in some cases this document, due to its genesis, contains contradictions. Please feel free to propose further changes or issues associated with this discussion. See you in Washington D.C. very soon. ---- Hiro Kishimoto

1 0

Re: [ogsa-wg] effective use of resource lifetimes in grid infrastructure
by Hiro Kishimoto 06 Dec '04

06 Dec '04

Steve's email bounced. ---- Hiro Kishimoto Subject: Re: [ogsa-wg] effective use of resource lifetimes in grid infrastructure Cc: ogsa-wg(a)ggf.org To: Steve Loughran <steve_loughran(a)hpl.hp.com> From: Steve Tuecke <tuecke(a)mcs.anl.gov> Date: Mon, 6 Dec 2004 09:52:17 -0600 Steve, The ManagedJob WS-Resource need not be hosted on the same host as the job itself. Here's a draft document that you might find useful that describes the GT4 WS GRAM approach in more detail: http://www-unix.globus.org/toolkit/docs/development/3.9.3/execution/ wsgram/WS_GRAM_Approach.html -Steve On Dec 6, 2004, at 7:12 AM, Steve Loughran wrote: > Ian Foster wrote: >> Steve: >> A variety of semantics and connections are possible between a >> "WS-Resource" and an "entity that the WS-Resource repesents", >> including both your (a) and (b) below. I don't believe that the >> implied resource pattern implies that one particular approach be >> adopted. >> The following are some rough notes on how we have chosen to handle >> things in the GT4 GRAM service. This may perhaps be relevant to your >> problem. >> The approach that we take in GT4 GRAM is as follows: >> 1) A GRAM ManagedJobFactory defines a "create job" operation that: >> a) creates a job, and also >> b) creates a ManagedJob WS-Resource, which represents the resource >> manager's view of the job. >> 2) The ManagedJob WS-Resource and the job are then linked as follows: >> a) Destroying the ManagedJob WS-Resource kills the job >> b) State changes in the job are reflected in the ManagedJob >> WS-Resource >> c) Termination of the job also destroys the ManagedJob WS-Resource, >> but not immediately: we find that you typically want to leave the >> managedjob state around for "a while" after the job terminates to >> allow clients to figure out what happened to the job after the fact >> Regards -- Ian. > > Ian, > > What is your fault tolerance strategy here? > > Is every ManagedJob WS-Resource hosted on the same host (and perhaps, > same process) as the job itself? > > This would mean that there is no way for the managedjob EPR to fail > without the job itself failing, but would require the entire set of > job hosts to be visible for inbound SOAP messages. And prevent you > moving a job from one node to another without some difficultly (the > classic CORBA object-moved problem, I believe, though HTTP 304 > responses would work if only SOAP stacks processed them reliably) > > I am trying to do a design which would enable (though would not > require) only a subset of nodes -call them portal nodes- to be visible > to outside callers, with the rest of the nodes only accessible to the > portal itself. Once I assume this architecture, modelling the > resources gets complex, as EPRs contain routing info that may become > invalid if a portal node fails. > > -steve > > >

1 0

effective use of resource lifetimes in grid infrastructure
by Steve Loughran 06 Dec '04

06 Dec '04

Hello, I am trying to design the CDDLM deployment API in the WS-RF style, and am having problems with understanding the best way to make effective use of resource lifetimes in a fault-tolerant environment. I would like some assistance : Scenario ======== -We are supporting automated deployment of applications to allocated resources. -Applications are deployed through a deployment portal; the applications may deployed on hosts that are not running the services necessary for direct communication, or behind a firewall. -The deployment portal is in a DMZ or otherwise reachable by all callers. All EPRs must therefore refer to the portal. I had originally envisaged that to destroy an application,a <wsrl:Destroy/> call could be made. Yet I have a problem. I want to be fault tolerant without relying on load balancing routers, round-robin DNS or mDNS hostnames. In the stateful resources pattern, I can have EPRs that contain policy on how to renew an EPR. Presumably that would list a service group location from whence any other deployment portal EPR could be found that could renew an invalid EPR for us (e.g. by extracting application identification info and constructing a new EPR referring to the local portal) This all seems workable, ignoring the problem of specifying the policy of updating EPRs. Presumably we'd have to do an app specific algorithm and policy. What is causing me trouble is resource lifetimes. Once I have a world in which you can have multiple EPRs all referring to the same resource, the same deployed application, what does that mean for WS-ResourceLifetime? If I have multiple, different EPRs, is it right that a <wsrl:Destroy/> call on one of them should terminate the final application? What if there was state on each portal related to the EPR that needed cleaning up at the end of a conversation, and so required either that destroy call, or timeout-initiated destruction? I think the problem here is "what should I be modelling with the implicit resource pattern"? . Is it:- (a) the resource in question *is* the application. When the resource is destroyed, so is the application. (b) the resource in question is merely a view of the application. When the resource is destroyed, the view goes away, but the application remains until destroyed by some other means. -Steve

2 3