May 2006 - ogsa-wg - lists.ogf.org

GGF17 information
by Hiro Kishimoto 05 May '06

05 May '06

Hi all, You can find some useful information for GGF17 at the following wiki site. Thanks Satoshi Matsuoka and Joel Replogle. http://testforge.ggf.org/sf/go/wiki1140 - General Directions from Narita airport to downtown Tokyo - Japan Cellular Phone Survival Guide for Foreign Visitors Hope it helps, -- Hiro Kishimoto

1 0

Resignation as Chair of OGSA-RSS
by Mathias Dalheimer 05 May '06

05 May '06

Hi all, during the preparation of the sessions for Tokyo this week, I noticed that I didn't contribute to OGSA-RSS in the last few months. Thinking about the reasons, I discovered two of them: I am sure this is true for all of us, but my time available for GGF is very limited. Due to other commitments in the last months, I wasn't able to spent more time on OGSA-RSS. The more important reason is that my work has changed in the last months. OGSA-RSS is going to define a scheduling interface which will be applicable to most grid schedulers. The interaction with an RSS- compliant consists of a simple request-response scheme, which is a sensible choice because of the interoperability such a scheme facilitates. My current work focus lies in an area where such a scheme is too simple. I think of a scheduler more in the sense of an agreement- finding and monitoring engine, which is a highly specialized view of the area. I think it is very hard to standardize more than the data formats, e.g. how to describe jobs, in this scenario. This is different from my starting point a year ago, when a mapping of my work to the OGSA-RSS seemed easy. I value the GGF as a place to meet people and exchange ideas, and I will continue to visit future GGFs for this. But I will resign as cochair of OGSA-RSS after GGF17. I hope you understand that I do not criticize the standardization efforts in GGF as a whole - in many other scenarios, the standardization has a lot of benefits. See you in Tokyo for good discussions, Mathias __________________________________________________________________ Dipl.-Wirtsch. Ing. (Inform.) Mathias Dalheimer Fraunhofer Institut fuer Techno- und Wirtschaftsmathematik (ITWM) Fraunhofer-Platz 1 67663 Kaiserslautern, Germany Phone +49(0)631/31600-4484 | mailto:dalheimer@itwm.fraunhofer.de Fax +49(0)631/31600-1099 | __________________________________________________________________

1 0

Version 6 of the information modeling guidelines
by Fred Maciel 05 May '06

05 May '06

Hi, I just uploaded a new version of the modeling guidelines document. I included most of the comments of the last F2F. I'm not showing in the document changes that just move text around. The latest version, as always, can be found at: https://forge.gridforum.org/projects/ogsa-wg/document/Modeling_Guideline s/en In the information model session in GGF17 the focus will be on Ellen's work, namely the position paper on the model for EMS (she is writing it as a separate document). We will only touch the guidelines document if there is plenty of time left in the session [please insert hysterical laughter here]. So if you have comments on the guidelines document, please grab me in the corridors in GGF17 or send an e-mail to the reflector. See you in Tokyo, Fred Maciel Hitachi America R&D The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in Hitachi America, Ltd. on the contents of this information is strictly prohibited and is unlawful. If you have received this communication in error, please notify us immediately by responding to this e-mail and then delete it from your system. Hitachi America, Ltd. is not liable for any improper and/or incomplete transmission of the information contained in this communication or for any delay in its receipt. Hitachi America, Ltd. is not responsible for any damage caused by malicious code or alteration by any third party. The contents of this e-mail do not necessarily represent the views or policies of Hitachi America, Ltd.

1 0

Re: [saga-rg] Re: [ogsa-bes-wg] Extensible state model for jobs
by Christopher Smith 04 May '06

04 May '06

I agree ... we can discuss this next week. -- Chris On 03/5/06 10:09, "Thilo Kielmann" <kielmann(a)cs.vu.nl> wrote: > Chris and Andre, > > I think we really should resolve this issue face-to-face next week at GGF17. > That will save a lot of email typing time... > > Andre, do we have a slot in one of our sessions? > > > Thilo > > On Wed, May 03, 2006 at 06:08:46PM +0200, Andre Merzky wrote: >> X-Original-To: kielmann@localhost >> Delivered-To: kielmann(a)localhost.cs.vu.nl >> Delivered-To: grdfm-saga-rg-outgoing(a)mailbouncer.mcs.anl.gov >> X-Original-To: grdfm-saga-rg(a)mailbouncer.mcs.anl.gov >> Delivered-To: grdfm-saga-rg(a)mailbouncer.mcs.anl.gov >> Date: Wed, 3 May 2006 18:08:46 +0200 >> From: Andre Merzky <andre(a)merzky.net> >> To: Christopher Smith <csmith(a)platform.com> >> Cc: Andre Merzky <andre(a)merzky.net>, >> "ogsa-wg(a)ggf.org" <ogsa-wg(a)ggf.org>, ogsa-bes-wg(a)ggf.org, >> SAGA RG <saga-rg(a)ggf.org> >> Subject: [saga-rg] Re: [ogsa-bes-wg] Extensible state model for jobs >> >> Quoting [Christopher Smith] (May 03 2006): >>> >>> On 03/5/06 05:36, "Andre Merzky" <andre(a)merzky.net> wrote: >>> >>>> Right now its absent because only those states which can be >>>> actually reached by SAGA method calls are present. Now, as >>>> you said earlier, it can be assumed a flaw that SAGA has no >>>> means to put a job into 'Pending' state. >>>> >>> >>>> So, if there are some use cases or some agreement that the >>>> API should allow to move a job into 'Pending' state, the >>>> method/attribute will be added, and the state will be added. >>>> >>> The state that a job enters after a create_job operation is 'pending', so >>> the create_job operation is the method that puts a job in this state. >> >> Right, I understand that from the queuing point I think. >> However, from the application level it does not matter, as >> it cannot actively change that state. We have no notion of >> queue states at all. >> >> Well, let me put it differently: what do we gain by moving >> the state to the higher level? It complicates the state >> diagram (not much, that is not the point), but does not >> allow to perform any new state transition from application >> level. >> >> As said, I would compare this to Suspended state: its >> clearly an important state in many systems, but as long as >> the API does not expose means to suspend/resume a job, the >> state is meaningless, and merily informative (e.g. the job >> gut suspended by a 3rd party, or by the backend). That >> information is exposed however, through the job state >> details - same holds for hols (ha!) I think. >> >> >>> This state is required for queuing systems ... I can't even imagine how it >>> got dropped from the state diagram. I think you're trying to map the task >>> state model too closely. ;-) >> >> Nono, that has nothing to do with the task states - they >> could easily leave that state out. Well, its very >> convenient to have the same model here, thats for sure ;-) >> >> >>>> Similar reasoning holds for 'Suspend' - as long as we don't >>>> have suspend/resume methods, we would not like to expose a >>>> 'Suspended' state on the higher level state diagram. >>> >>> This I agree with. >> >> As said, it might well be that SAGA is broken in the respect >> that we doesn't allow job.hold (), or submit into hold. >> Well, it wasn't in the use-cases ... :-P >> >> Cheers, Andre. >> >> >>> -- Chris >> >> >> >> -- >> "So much time, so little to do..." -- Garfield >> > >

2 2

CFP GridNets 2006 : DEADLINE APPROACHING
by Antoine.Pichot＠alcatel.fr 04 May '06

04 May '06

Call for Papers =============== GridNets 2006 Third International Workshop on Networks for Grid Applications Co-Sponsored by IEEE Communications Society and Create-Net Co-located with IEEE Communications Society/Create-Net Broadnets 2006 San Jose, California, USA, October 1-2, 2006 http://www.gridnets.org Grid developers and practicioners are increasingly realising the importance of an efficient network support. Entire classes of applications would greatly benefit by a network-aware Grid middleware, able to effectively manage the network resource in terms of scheduling, access and use. Conversely, the peculiar requirements of Grid applications provide stimulating drivers for new challenging research towards the development of Grid-aware networks. Cooperation between Grid middleware and network infrastructure driven by a common control plane is a key factor to effectively empower the global Grid platform for the execution of network-intensive applications, requiring massive data transfers, very fast and low-latency connections, and stable and guaranteed transmission rates. Big e-science projects, as well as industrial and engineering applications for data analysis, image processing, multimedia, or visualisation just to name a few are awaiting an efficient Grid network support. They would be boosted by a global Grid platform enabling end-to-end dynamic bandwidth allocation, broadband and low-latency access, interdomain access control, and other network performance monitoring capabilities. The Gridnets 2006 workshop will provide a focused and highly interactive forum where researchers and technologists will have the opportunity to present and discuss leading research, developments, and future directions in the Grid networking area. As an IEEE publication, the proceedings will also be accessible through the IEEE Xplore website and other digital libraries. Best papers will be considered for publication in a special section of Elsevier Future Generation Computer Systems (FGCS) - The International Journal of Grid Computing: Theory, Methods and Application". Scope ------ The GridNets 2006 workshop will focus on research issues and challenges as well as lessons learned from experience. Topics of interest include and are not limited to: * New concepts and requirements to shape the design of eScience and Research Networks * Integration of advanced optical networking technologies and architectures (OPS, OBS) for the Grid environment * Coordination of network resources with other Grid resources (CPU, Storage) * Layer interactions: optical layer with higher layer protocols * Grid advanced resource reservation * Self-healing Grid networks * Traffic characteristics and performance analysis * New architectures and technologies that address Grid requirements * Experience on production-level optical network infrastructures * Middleware design and grid layer integration issues for accessing and managing network resources * Routing and scheduling for dynamic bandwidth control * Monitoring, provisioning, brokering of network resources * New multi-service frameworks and models * End-to-end application level control of network resource * Peer-to-peer approach for Grid networks * Network support for wireless Grids * Novel data transport protocols designed for new application services * Data replication and multicasting strategies and protocols * Fault-tolerance, protection, security, and scalability issues related to connecting large number of sites * Network cost, performance, and incentive issues * Grid network simulation * Identification of Grid peculiarities that network mechanisms can build upon Important Dates ----------------- Paper Submission Deadline: May 26, 2006 Paper Acceptance Notification: June 30, 2006 Final paper submission: July 31, 2006 (For submission instructions, refer to http://www.gridnets.org ) Organizing Committee ==================== Workshop co-chairs: Pascale Vicat-Blanc Primet (ENS Lyon), Michael Welzl (University of Innsbruck) Workshop vice-chair: Piero Spinnato (Create-Net) Technical Program Committee chair: Wayne Clark (Cisco) Panel chair: Bela Berde (Alcatel) Publicity chair: Antoine Pichot (Europe) (Alcatel), Tomohiro Kudoh (Asia) (AIST), Brian Tierny (USA) (LBL) Steering Committee: Imrich Chlamtac (Create-Net), Gigi Karmous-Edwards (MCNC), Michael Welzl (University of Innsbruck) Conference coordination and registration: Kitti H. Kovacs (ICST) Program Committee ================= Bill Allcock - Argonne National Lab Micah Beck - University of Tennessee Augusto Casaca - INESC Piero Castoldi - Scuola Superiore Sant'Anna Cees De Laat - Universiteit van Amsterdam Peter Dinda - Northwestern University Jose Fernandes - FCCN Tiziana Ferrari - INFN - CNAF Gabriele Garzoglio - Fermi National Lab Wolfgang Gentzsch - D-Grid Wolfgang Gerteis - SAP Belfast Doan Hoang - University of Technology, Sydney David Hutchison - Lancaster University Adriana Iamnitchi - University of South Florida Admela Jukan - Universite de Quebec Jussi Kangasharju - Technical University Darmstadt Gigi Karmous-Edwards - MCNC Dieter Kranzlmüller - University of Linz Joe Mambretti - Northwestern Univ Max Mühlhäuser - Technical University Darmstadt Nicholas Race - Lancaster University Matei Ripeanu - University of British Columbia Volker Sander - University of Applied Sciences Aachen Dimitra Simeonidou - University of Essex Oliver Yu - University of Illinois at Chicago

1 0

RE: [ogsa-wg] Thoughts on extensions mechanisms for the HPC profile work
by Dave Berry 04 May '06

04 May '06

Hi Marvin, It seems strange to me to limit yourself to a list of identifiers as a means of interacting with large numbers of jobs. Wouldn't it be more flexible to allow more complex expressions, such as "all jobs submitted by Marvin that use more than 4 processors and are currently running" (or whatever). You could build an appropriate information model, map it to a data model and provide a corresponding query language that clients could use to request the information they need. I agree that this is a service-oriented approach rather than a resource-oriented approach. However, having set up a particular query, you might want to repeatedly interact with the current state of that query. So it might make sense to register the query with the service and return an EPR that can be used to get the current set of results. I don't see much point in passing back an abstract name (e.g. a UUID) on its own. Without a reference to a resolution mechanism, clients won't be able to make much use of it. This is why URL's and URI's have been so successful; they include enough information for any client to know which mechanism to use to resolve them. This seems to be one advantage of the WS-Name proposal; it includes an abstract name with a reference to a resolution mechanism. Is it still the case that BES containers are allowed (or even encouraged) to return WS-Names? Would it be useful to have a means for composing WS-Name EPRs that use the same resolution mechanism in order to make a single WS-Name that can be used to query all of them? Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marvin Theimer Sent: 29 April 2006 03:06 To: ogsa-wg(a)ggf.org Subject: [ogsa-wg] Thoughts on extensions mechanisms for the HPC profile work * Support for array operations and other forms of batching. * When 1000's of jobs are involved the efficiency gains of employing array operations for things like queries or abort requests are too significant to ignore. Hence a model in which every job must be interacted with on a strictly individual basis via an EPR is arguably unacceptable. * One approach would be to simply add array operations alongside the corresponding individual operations, so that one can selectively interact with jobs (as well as things like data files) in either an "object-oriented" fashion or in "bulk-array" fashion. One could observe that the array operations enable the corresponding individual operations as a trivial special case, but this would arguably violate the principle of defining a minimalist base case and then employing only extensions (rather than replacements). * Array operations are an example or a service-oriented rather than a resource-oriented form of interaction: clients send a single request to a job scheduler (service) that refers to an array of many resources, such as jobs. This raises the question of whether things like jobs should be referred to via EPRs or via unique "abstract" names that are independent of any given service's contact address. At a high level, the choice is unimportant since the client submitting an array operation request is simply using either one as a unique (and opaque) identifier for the relevant resource. On a pragmatic level one might argue that abstract names are easier and more efficient to deal with than EPRs since the receiving scheduler will need to parse EPRs to extract what is essentially the abstract name for each resource. (Using arrays of abstract names rather than arrays of EPRs is also more efficient from a size point-of-view.) * If abstract names are used in array operations then it will necessary that individual operations return the abstract name and not just an EPR for a given resource, such as a job. If this approach is chosen then this implies that the base case design and implementation must return abstract names and not just EPRs for things like jobs.

3 3

Extensible state model for jobs
by Christopher Smith 03 May '06

03 May '06

Hi all, As Marvin mentioned in his email on extensibility and composition of protocols, I'd like to present this short document describing, in more detail, a model for extending the state model of jobs from a "base profile". The document is based on some discussions that Marvin and I have been having about scheduler interoperability, and is very close to the model that has been proposed within the SAGA working group. Please review Marvin's email about extensibility to get a feel for the "context" of the model. It is my intention to show how the ESI and BES state models can be represented using this approach. I'll try to get that done before Tokyo, but might just need to present some slides at GGF17, assuming I'm given a few minutes to do so. This is very much a work in progress, so I'm looking forward to feedback.... A note for the SAGA group .... I'd still like to see "pending" in the base job state diagram ... don't know why it disappeared. ;-) -- Chris

2 3

Re: ws-naming telcon tomorrow (Wednesday)? Re: [ogsa-naming-wg] RE: Minutes and next meeting
by Frank Siebenlist 03 May '06

03 May '06

I am on the naming mailing list, but I did not see any confirmation whether or not this telcon was going to happen and what the associated telcon info would be... Thanks, Frank. Andrew Grimshaw wrote: > Yes, It was in the last email. Which of course you did not get because you > are not on the email list. > > The dial in is: > > Toll Free: 866-231-9615 > > Long Distance: 713-576-2028 > > Participant Code: 255921 > > > There will be glance. > > > >> -----Original Message----- >> From: Frank Siebenlist [mailto:franks@mcs.anl.gov] >> Sent: Tuesday, May 02, 2006 7:02 PM >> To: Andrew Grimshaw >> Cc: ogsa-naming-wg(a)ggf.org; ogsa-wg(a)ggf.org >> Subject: ws-naming telcon tomorrow (Wednesday)? Re: [ogsa-naming-wg] RE: >> Minutes and next meeting >> >> Hi Andrew, >> >> Will we have another telcon tomorrow at 11am EDT? >> >> If so, is there any telcon# >> >> Thanks, Frank. >> >> >> Frank Siebenlist wrote: >> >>> I can make this ws-naming Wed 11am EDT telcon. >>> >>> -Frank. >>> >>> Andrew Grimshaw wrote: >>> >>> >>>> All, >>>> >>>> I committed to 11 AM Tuesday without checking my calendar. I have a >>>> >> PhD >> >>>> proposal to attend: >>>> >>>> "Federated Trust Management in Service Oriented Architectures". (Not >>>> >> one of >> >>>> my students.) >>>> >>>> >>>> >>>> I would like to propose that we "meet" Wednesday at the same time. >>>> >> Please >> >>>> respond if you cannot make that time - and were planning on attending. >>>> >>>> >>>> >>>> >>>> >>>> A >>>> >>>> >>>> >>>> _____ >>>> >>>> From: Andrew Grimshaw [mailto:grimshaw@cs.virginia.edu] >>>> Sent: Friday, April 28, 2006 1:03 PM >>>> To: 'ogsa-naming-wg(a)ggf.org' >>>> Subject: Minutes and next meeting >>>> >>>> >>>> >>>> All, >>>> >>>> Attached are the minutes from today's teleconference. Minutes are >>>> >> also on >> >>>> gridforge. >>>> >>>> The next teleconference is Tuesday, May 2, at 11AM Eastern. >>>> >>>> The dial in is: >>>> >>>> Toll Free: 866-231-9615 >>>> >>>> Long Distance: 713-576-2028 >>>> >>>> Participant Code: 255921 >>>> >>>> >>>> >>>> Glance will be provided at ogsa.glance.net >>>> >>>> >>>> >>>> Agenda: >>>> >>>> >>>> >>>> Agenda bashing >>>> >>>> Approve minutes >>>> >>>> Continue discussion of WS-Naming modifications to make consistent >>>> >> with draft >> >>>> requirements document. >>>> >>>> Go through tracker >>>> >>>> >>>> >>>> A >>>> >>>> >>>> >>>> Andrew Grimshaw >>>> >>>> Professor of Computer Science >>>> >>>> University of Virginia >>>> >>>> 434-982-2204 >>>> >>>> grimshaw(a)cs.virginia.edu >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> -- >> Frank Siebenlist franks(a)mcs.anl.gov >> The Globus Alliance - Argonne National Laboratory >> > > -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

Re: [ogsa-naming-wg] RE: Minutes and next meeting
by Frank Siebenlist 02 May '06

02 May '06

I can make this ws-naming Wed 11am EDT telcon. -Frank. Andrew Grimshaw wrote: > All, > > I committed to 11 AM Tuesday without checking my calendar. I have a PhD > proposal to attend: > > "Federated Trust Management in Service Oriented Architectures". (Not one of > my students.) > > > > I would like to propose that we "meet" Wednesday at the same time. Please > respond if you cannot make that time - and were planning on attending. > > > > > > A > > > > _____ > > From: Andrew Grimshaw [mailto:grimshaw@cs.virginia.edu] > Sent: Friday, April 28, 2006 1:03 PM > To: 'ogsa-naming-wg(a)ggf.org' > Subject: Minutes and next meeting > > > > All, > > Attached are the minutes from today's teleconference. Minutes are also on > gridforge. > > The next teleconference is Tuesday, May 2, at 11AM Eastern. > > The dial in is: > > Toll Free: 866-231-9615 > > Long Distance: 713-576-2028 > > Participant Code: 255921 > > > > Glance will be provided at ogsa.glance.net > > > > Agenda: > > > > Agenda bashing > > Approve minutes > > Continue discussion of WS-Naming modifications to make consistent with draft > requirements document. > > Go through tracker > > > > A > > > > Andrew Grimshaw > > Professor of Computer Science > > University of Virginia > > 434-982-2204 > > grimshaw(a)cs.virginia.edu > > > > > -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 1

please add me to the ws-naming gridforge project members...
by Frank Siebenlist 02 May '06

02 May '06

Not sure what the "procedure" is to get this accomplished, but i've tried clicking on the "Request Project Membership", emailed admins, send email to the ws-naming list... it's almost as I'm not welcome to join ;-) -Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0