- ogsa-wg - lists.ogf.org

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

RE: Survey template v06
by Hiro Kishimoto 06 Dec '04

06 Dec '04

Hi all, Andreas and I revised the survey template and its example answer. If you have assigned to response to this survey at the upcoming F2F meeting, please get to work on. Thanks, ---- Hiro Kishimoto > -----Original Message----- > From: Hiro Kishimoto [mailto:hiro.kishimoto@jp.fujitsu.com] > Sent: Monday, November 29, 2004 9:06 PM > To: 'ogsa-wg' > Subject: RE: Survey template (RE: [ogsa-wg] Proposed agenda for Nov. 24th call) > > Hi all, > > At the last Wednesday call, I've got homework assignment to revise > survey template based on the useful comments at the call. Attached file > is a revised survey template (rev. 05) and corresponding Business Grid > answer example. > > Thank you very much for your valuable comments, they are far better > than the first one. > > As usual, they are also in the GridForge: > http://tinyurl.com/5fxfd/OGSA_interested_party_survey > http://tinyurl.com/5fxfd/BusinessGrid_draft > > Thanks, > ---- > Hiro Kishimoto > > > > -----Original Message----- > > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Hiro > > Kishimoto > > Sent: Wednesday, November 24, 2004 6:28 PM > > To: 'ogsa-wg' > > Subject: Survey template (RE: [ogsa-wg] Proposed agenda for Nov. 24th call) > > > > Hi all, > > > > > 2) Interested party list discussion (30 min) > > > For both our roadmap and v1 document, we should list up key > > > stakeholders including WG/RG/TCs, grid projects, venders. > > > Identify their interest (high level arch - actual spec - > > implementation) > > > and involvement to OGSA activity. > > > Hiro will send out draft survey template before the call. > > > > Please find draft template for interested party survey. > > I also included first draft of Business Grid as an example. > > > > https://forge.gridforum.org/projects/ogsa- > wg/document/OGSA_interested_party_surv > > ey/en/1 > > > > https://forge.gridforum.org/projects/ogsa-wg/document/BusinessGrid_draft/en… > > > > Thanks, > > ---- > > Hiro Kishimoto

2 2

NO OGSA call on Dec. 6th
by Hiro Kishimoto 06 Dec '04

06 Dec '04

Hi all, Since we will have a three day F2F meeting in Washington D.C., we do not have a regular Monday call on Dec. 6th. Have a safe trip and see you very soon, ---- Hiro Kishimoto

1 0

Data: Minutes of the telcon on 1st December
by Dave Berry 03 Dec '04

03 Dec '04

Dear all, I attach the minutes for the telcon on 1st December, which you can also find on GridForge at: https://forge.gridforum.org/projects/ogsa-wg/document/Minutes_1st_Decemb er_2004/en/1. I have still to confirm the date of the next telcon. Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

Naming: ARK identifiers?
by Dave Berry 30 Nov '04

30 Nov '04

For the naming team, Have you looked at the ARK naming scheme from J Kunze? There is an IETF draft describing this: http://www.ietf.org/internet-drafts/draft-kunze-ark-08.txt. ARK identifiers have the form [http://NMAH/]ark:/NAAN/Name. The NAAN/Name part seems very similar to the Handle system. The optional NMAH part defines a service that can resolve the name. The ARK scheme proposes that naming authorities commit to (and make explicit) a policy for the persistence of the object. By the way, what is it about the Handle system that doesn't satisfy the uniqueness property (c.f. the comparison spreadsheet)? Dave. -----Original Message----- From: Andrew Grimshaw [mailto:grimshaw@virginia.edu] Sent: 29 November 2004 18:23 To: 'Hiro Kishimoto'; 'ogsa-wg' Subject: RE: [ogsa-wg] naming service design team call on Nov 29th I have not had a chance to write the revised document. We can however, discuss the one item we punted on - names and authentication. Andrew -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Hiro Kishimoto Sent: Friday, November 26, 2004 2:15 AM To: 'ogsa-wg' Subject: [ogsa-wg] naming service design team call on Nov 29th Hi all, We will have an name service design team call on Nov. 29th Monday from 5pm to 7pm (CST). Andrew will send out revised naming document before the call. He will lead security aspect discussion with Frank, our security guru. The dial-in number for Monday; Free: +1-866-639-4741 Toll: +1-574-935-6703 PIN: 8980700 Screen share service will be provided. URL: http://hiro.glance.net Session key: 1129 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html Previous calls minutes: (Nov. 15) Mark has uploaded the previous meeting minutes. https://forge.gridforum.org/projects/ogsa-wg/document/naming-minutes-200 4111 5/en /1 Thanks, ---- Hiro Kishimoto

1 0