- ogsa-wg - lists.ogf.org

2nd Call for papers- Workshop "Semantic InformationIntegration on Knowledge Discovery"-(SIIK 2006)
by Nguyen Manh Tho 24 Jul '06

24 Jul '06

Apologies for multiple copies due to cross postings. Please send to interested colleagues and students) CALL FOR PAPERS ---------------------------------------------------------------------------- The 1st International Workshop "Semantic Information Integration on Knowledge Discovery" - (SIIK 2006) ---------------------------------------------------------------------------- http://www.ares-conf.org/siik in conjunction with the 8th International Conference on Information Integration and Web Based Applications & Services (iiWAS2006)-http://www.iiwas.org/conferences/iiwas2006/ 4-6 December 2006, Yogyakarta, Indonesia. Introduction ------------- Knowledge Discovery has been widely accepted as a key technology for enterprises and organizations to improve their abilities in data analysis, decision support, and the automatic extraction of knowledge from data. With the exponential growing amount of information to be included in the decision making process, the data to be considered becomes more and more complex in both structure and semantics, located in heterogeneous and distributed systems. Furthermore, the explosive growth and popularity of the world-wide web has resulted in a huge number of information sources on the Internet. Consequently, the process of retrieval and knowledge discovery from this huge amount of heterogeneous complex data builds the litmus-test for the research in the area. Information Integration subsumes all technologies needed to provide form manipulation of information scattered over many information systems while supporting a single system image. Information integration has been a long standing challenge for the database community in the last decades. Although there are several distinct research and development areas explicitly or implicitly addressing data integration, the schematic and semantic heterogeneity is still one of the most difficulties in the integration of heterogeneous knowledge and information systems - one of the perquisite steps of knowledge discovery process. The purpose of this workshop is to bring together researchers, developers, and practitioners to present their recent work, discuss and identify problems, synergize different views of techniques and policies, and brainstorm future research/development directions on semantic information integration used in knowledge discovery. The research on progress, draft idea, architecture submissions are also welcome. Particularly, we strongly encourage submissions dealing with real world applications such as information integration in science information systems, health-care systems, e-government, e-commerce, workflow management systems, web information systems, etc. Topics of interests ------------------- The topics of the workshop include, but are not limited to: - Standards based Information Integration - Managing metadata for information integration - Semantic Integration - Information extraction - Information quality/data cleaning - Resolving inconsistency across sources - Ontologies for Information Integration - Ontology mapping and merging - Schema mapping/evaluating/integrating - On-the-fly Integration - Secure Information Integration - Information Integration architectures - Reviews and evaluation of existing Integration approaches - Tools for supporting Information Integration - Data Integration in data warehousing/ data mining - Data integration in P2P/Grid systems - Data Integration in Health Care systems - Data Integration in e-Commerce applications - Data Integration in e-Government applications - Data Integration in e-Science applications - Data Integration Management for mobile applications - Workflow Information Integration - Data Integration across Institutional Borders Submission Instructions ----------------------- The SIIK workshop accepts full and short research papers. For paper registration and electronic submission please use the following website: http://www.ares-conf.org/siik/review The length of the full paper should not exceed 10 pages and short paper should not exist 5 pages. Papers must be formatted according to the guidelines of the Austrian Computer Society (OCG). (to be found at http://www.ocg.at/activities/books/Richtlinien.pdf) Submitted papers will be blind reviewed and carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. Duplicate submissions are not allowed. A submission is considered to be a duplicate submission if it is submitted to other conferences/workshops/journals or it has been already accepted to be published in other conferences/workshops/journals. Duplicate submissions thus will be automatically rejected without reviews. The submission implies that at least one author must register at the iiWAS conference and present the paper. Important Dates --------------- September 15, 2006 Full Papers submission October 6, 2006 Acceptance Notification October 15, 2006 Camera-Ready Papers December 4-6,2006 Workshop at iiWAS Conference Publication ------------ All accepted workshop papers will be published in the Austrian Computer Society book series. Distinguished papers, after further revisions, will be published in special issues of : [1] International Journal of Web Information Systems (http://www.troubador.co.uk/ijwis) [2] International Journal of Web and Grid Services (https://www.inderscience.com/browse/index.php?journalID=47) [3] International Journal of Business Intelligence and Data Mining (https://www.inderscience.com/browse/index.php?journalID=143) [4] More are pending approval Workshop Organizers ------------------- Nguyen Manh Tho, Ph.D. (main contact) Institute of Software Technique and Interactive System, Vienna University of Technology , Favoriten strasse 9-11/188 A1040 Vienna, Austria tho(a)ifs.tuwien.ac.at Benhard Sitohang, Ph.D. School of electrical engineering & Informatics, Bandung Institute of Technology, Indonesia Benhard(a)informatika.org Programme Committee ------------------- Ahmad Ashari, Universitas Gadjah Mada, Indonesia Andrea Cali, Free University of Bozen-Bolzano, Italy R. Scott Cost, The Johns Hopkins University, USA Mohand-Said Hacid, University Lyon 1, France Danile Herin, Montpellier II University. LIRMM, France Ela Hunt, ETH Zurich, Switzland Ralf-Detlef Kutsche, TU Berlin & Fraunhofer ISST, Germany Ramon Lawrence, University of British Columbia Okanagan, USA Domenico Lembo, University of Roma "La Sapienza", Italy Giansalvatore Mecca, Universita' della Basilicata, Italy Marco Mesiti, DICO - University of Milano, Italy Tho Manh Nguyen, Vienna University of Technology, Austria Marta Sabou, KMi, The Open University, UK Benhard Sitohang, School of electrical engineering & Informatics - ITB, Indonesia Putri Saptawati, Institut Teknologi Bandung, Indonesia Laurentiu Vasiliu, DERI, National Unversity of Ireland, Galway, Ireland Basuki Widodo, Institut Teknologi Sepuluh November, Indonesia Huiyong Xiao, University of Illinois at Chicago, USA Takahira Yamaguchi, Keio University, Japan

1 0

No call on July 24 and 27
by Hiro Kishimoto 22 Jul '06

22 Jul '06

Hi all, Thank you very much for all of you who came to or dialed in July F2F meeting in Chicago. We have had very lively and productive sessions and established several very important agreement. You can double check on them by meeting minutes; they are already in GridForge folder. We also thanks for our excellent note takers; Andreas Savva, Michel Drescher, Chris Jordan, and others. Following our tradition, we won't have conf calls on July 24th and 27th. Our next call will be July 31st Monday. Thanks again and I hope you all safe trip back home! -- Hiro Kishimoto

1 0

POSIX component CDL design
by Hiro Kishimoto 20 Jul '06

20 Jul '06

Hi all, Jun Tatemura's document "Designing a POSIX Component in CDL" is now on GridForge. Many thanks Jun!! https://forge.gridforum.org/sf/go/doc13685?nav=1 We will review and discuss it at Today's first session. OGSA July F2F meeting, day four July 20 (Thu) 8:30-10:20am (CDT) Joint CDDLM session CDDLM WG (Jun Tatemura and Hiro Kishimoto) GGF18 session plan (110 min) - Complete CDDLM scenario and related CDDLM documents Dial-in: US Toll number: +1 408-961-6509 (San Jose) and +1 718-354-1071 (New York) UK Toll number: +44 (0)207 365-5269 JP Toll number: +81 (0)3 3570 8225 The pass code: 4371991 Thanks, -- Hiro Kishimoto

1 2

JSDL support in GRAM
by Ian Foster 19 Jul '06

19 Jul '06

Hi, Some people asked me about this issue, so I thought this email me might be of interest. Peter Lane (lead GRAM developer) tells me that a first prototype of JSDL support in GRAM has been completed. For those wanting to learn more, details are at http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=4545. Feedback, or volunteers for early evaluation, would be welcome. Peter notes that he has been able to submit the following simple JSDL job using the JsdlGramJob class: <?xml version="1.0" encoding="UTF-8"?> <jsdl:JobDefinition xmlns:jsdl="<http://schemas.ggf.org/jsdl/2005/11/jsdl>http://schemas.ggf.org/jsdl/2005/11/jsdl"> <jsdl:JobDescription> <jsdl:Application> <jsdl-posix:POSIXApplication xmlns:jsdl-posix="<http://schemas.ggf.org/jsdl/2005/11/jsdl-posix>http://schemas.ggf.org/jsdl/2005/11/jsdl-posix"> <jsdl-posix:Executable>/bin/date</jsdl-posix:Executable> </jsdl-posix:POSIXApplication> </jsdl:Application> </jsdl:JobDescription> </jsdl:JobDefinition> Regards -- Ian.

1 0

OGSA presentation in Management Developer's Conference 2006?
by Fred Maciel 19 Jul '06

19 Jul '06

Folks, Tom Roney and I are being asked if the OGF is going to present in this year's Management Developer's Conference. Apparently the OGF is too busy with the merger to think of presentations right now, but I'm suggesting that the OGSA could do a presentation, as we did last year. For an overview of OGSA we can use the slides from the Webcast (I can do this one, unless it overlaps with other stuff I'm presenting). But, as the name of the conference says, it's targeted torwards developers (i.e., people sitting down and writing code) of management stuff. A very good thing to do would be to show what kinds of middleware, tooling, etc. exist to build OGSA applications. The ideal thing to do would be to show (simple) code on the spot (lasy year in the WS-Management session a person from Intel wrote code on the spot to get the attributes of the CPU of the laptop he was using to present -- that was cool). Since everybody is meeting there in Chicago, could you allocate 10 minutes and make a decision on that? The deadline to get sessions is very close (I forgot the date. Tom?). I can dial in if needed (ping me through IM or on the phone). Thanks in advance, Fred Maciel Hitachi America R&D

1 0

Roadmap Session slides uploaded
by Christopher Jordan 19 Jul '06

19 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've uploaded the slides for tomorrow's Roadmap document session to GridForge: https://forge.gridforum.org/sf/go/doc13676?nav=1 Hiro, I'd appreciate it if you could run the glance session for me again. Thanks. - ---------------------------------------------------- Chris Jordan HPC Systems Engineer High End Computing Systems Group San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEvYClPCVtcXn6kg8RAmGKAKCPy5rUnOyqfS3tAQvo1ue1HRf+NwCeNZTE L85xxdShLgJGaNQbyxEU0y4= =cmT2 -----END PGP SIGNATURE-----

1 0

RE: [ogsa-wg] FINAL CALL: OGSA 1.5 Architecture and Glossary
by Dave Berry 18 Jul '06

18 Jul '06

I note that two of the diagrams in my presentation yesterday, titled "Basic Structure" and "Composite Entities", are including in the OGSA 1.5 document. In due course I will be reworking the version of these diagrams in the Data Architecture document, in the light of comments received. Would you like me to revise these now, so that the OGSA 1.5 document can be updated, or shall we take the OGSA 1.5 document as reflecting the current state of play in an evolving game? Dave. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Andreas Savva > Sent: 12 July 2006 04:49 > To: 'ogsa-wg' > Subject: [ogsa-wg] FINAL CALL: OGSA 1.5 Architecture and Glossary > > Final drafts of the OGSA 1.5 documents ([Arch] and [Glossary]) are > available on Gridforge. These drafts were updated according > to comments > received and subsequent teleconference reviews. The drafts are > change-tracked relative to the previous draft versions. > > Please comment on the list, this Thursday's call, or at the F2F next > week. The plan is to submit back to the GGF Editor > *after the end of the Interim Meeting next week, July 20 (Thursday).* > > [Arch] > https://forge.gridforum.org/sf/go/doc13553?nav=1 > > [Glossary] > https://forge.gridforum.org/sf/go/doc13555?nav=1 > > -- > Andreas Savva > Fujitsu Laboratories Ltd > >

2 1

Notes from yesterday's F2F data session
by Dave Berry 18 Jul '06

18 Jul '06

These are notes I made from the comments made during yesterday's presentation. I stress that we encourage people to review the documents and give us feedback. I also think it is urgent that we produce a common subset of scenarios combining EMS & Data services. 1. All references to "profiles" in the presentation should have been to "further normative specifications" - which may include profiles where appropriate. The primary point is that we need to encourage key specs and to incorporate them into the OGSA Roadmap. 2. The slides did not clarify that the "Architecture" takes a toolbox approach, rather than a predefined relationship between the services. 3. The diagram showing the relationships between interfaces, services & resources should allow multiple resources per service. It should use the same style as the later diagrams (i.e. showing services & resources separately rather than as concentric layers). 3a. The Architecture and Services documents should use the same diagram styles - probably the one used in the OGSA 1.5 document. 4. The "Basic Structure" diagram should add a "Storage Access" interface (or perhaps just a sink/source interface for data transfer). Also, "Other Data Services" should be renamed to "Data Management" - there is no intention to distinguish these services per se from the other "Data Management" services in the diagram. Note: This diagram also appears in the OGSA 1.5 document. 5. The "Composite Entities" diagram should include a "federation management interface" and a "cache management interface". I got the impression that the diagram was not successful in showing that the federation and cache services exposed the same interfaces as their "supplier" services; it might be better to repeat these interfaces on the federation and cache services rather than using the dotted line. Note: This diagram also appears in the OGSA 1.5 document. 6. An alternative implementation of the Data Pipelining scenario could use StreamableByteIO between the Visualisation service and the stored animations. It might be worth giving this example to show the different ways that the services can be used to implement a solution. 7. The "Bringing data online" scenario should clarify why data transfer is used instead of data access. Perhaps the phrase "read files" should be changed to "transfer files". 8. In the "Data Staging" scenario, the "Parameter Space Exploration Service" should probably be replaced by a script engine or workflow enactment engine. 9. There was a discussion about the meaning of the term "policy". It was suggested that the sample "policies" listed on the slides were better described as sample parameters for policies. The Data Architecture document attempts to use the term policy consistently and we'd be happy to take guidance on improving this presentation. 10. The slide about "Common Properties" was floating an idea. The comments from the group were that if these properties were to be generalised, then the ParentDataResource should be an EPR instead of a URI and should allow multiple parents. Also, the "Sensitivity" properties were basically an expression of the consistency model, which in the general case could be more complex (as indeed we have noted elsewhere in the Data Architecture document). 11. Some of the functionality of the WS-DAI (optional) CoreResourceList interface will be provided by the WS-Naming facility - specifically the the functionality of the Resolve operation. RNS is not the appropriate reference here because it deals in strings instead of URIs. The other operation provided by the CoreResourceList interface, GetDataResourceList, does not belong with WS-Naming (and perhaps would better fit with the possibly-generic properties on the previous slide). 12. DFDL was mentioned in the discussion about "OGSA Data gaps", as a possible mechanism for describing file "schemas". In fact the slide was simply referring to POSIX-style "stat" information but we do see DFDL as a potential description mechanism. The current section on "Data Description" in the Data Architecture document probably needs some fleshing out to consider possible languages in more detail. 13. There was some discussion of what is meant by a "data service". The terminology used in the Data Architecture document is that "Data Services" are the subset of the OGSA services that deal with data and hence include services for data transfer, data access, data replication, storage management, etc. There is an alternative body of opinion that data access services should be terminologically privileged, i.e. that the term "data service" should mean a data access service. 14. Regarding the Information Model, Jay mentioned that a key piece of information is whether a data resource is logically "near" another resource. This is of use to schedulers, workflow enactments and applications trying to choose which data resource to use, among other examples. It isn't clear how to incorporate this information into an information model (although this should not stop us developing other aspects of that model). I encourage everyone to review the Data Architecture and Data Services documents. These documents will be released under the OGSA brand and we are at a good stage to take on board any comments. Best wishes, Dave Berry Deputy Director, Research & E-infrastructure Development National e-Science Centre, 15 South College Street Edinburgh, EH8 9AA +44 131 651 4039

1 0

RE: [ogsa-wg] FINAL CALL: OGSA 1.5 Architecture and Glossary
by Subramaniam, Ravi 18 Jul '06

18 Jul '06

Hi, David: I agree with the modifications. But while we are on the topic I think Karl's point on BETWEEN and REGARDING is along the lines of what I was thinking but I guess where I was taking this was in the distinction between "establishment" and "honoring/binding" of agreement. The establishment can be done between two parties (e.g. between lawyers in the real world) but is binding on the parties (either singly or multiply(sp?)) that have delegated to the establishers. In this example, the lawyers are not the "legally bound parties" though they were instrumental in setting up the agreement. (The analogy in the grid could be pools that span hard boundaries (e.g. organizational).) In this case though there is a single agreement, it is between multiple parties (each playing a role and executing a responsibility as per the agreement). So from the "binding" view/perspective the agreement is between multiple parties but from the establishment perspective it is one-one. I have been taking agreement to be more closely tied to the "honoring/binding" and less to the "establishment" since higher order decisions can be made on an agreement if there is a reasonable "guarantee" that it will be honored. Advisory agreements have their place but I don't see that as the dominant model. Would it be accurate to observe that where the disconnect here is that the view taken in the thread is that the establishment is the key and hence having that bi-party is desired but I have taken the "binding/honoring view" where the referenced parties define the agreement? BTW: I agree with the comments on the consumer/producer roles are not fixed. If I did come across as otherwise it was inadvertent. I actually used the term provider which I envisioned as including consumer and/or producer and additional aspects like say manageability. Ravi -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of David Snelling Sent: Friday, July 14, 2006 1:24 AM To: Karl Czajkowski Cc: Subramaniam, Ravi; Andreas Savva; ogsa-wg Subject: Re: [ogsa-wg] FINAL CALL: OGSA 1.5 Architecture and Glossary Karl, On 14 Jul 2006, at 06:22, Karl Czajkowski wrote: > On Jul 13, Subramaniam, Ravi modulated: >> Hi David, >> >> I see what you are saying and I did consider that. The glossary term >> implied a "many to one" or "one to one" situation - one provider. >> What I >> was suggesting is a "one to many" situation which is very likely. >> So the >> situation where you have multiple providers accepting to an agreement >> (which at a higher level may be a single contract between domains) is >> still a "one to many" situation that the glossary term should cover. >> Right? >> >> Ravi >> > > > If you want to be general, I think the agreement should be BETWEEN two > parties (i.e. the legally bound parties) but REGARDING multiple > services, some of which may be provided (directly or indirectly) by > either party. +1, but all services involved must be referenced in the agreement. > I also think the important thing is to realize that the services must > be described clearly in terms of domain-specific operating > constraints, including the roles/responsibilities of the agreeing > parties. It is folly to try to state these roles in general about the > agreement parties in isolation from the service-specific models. > > The idea of who is the "producer" and the "consumer" is really > domain-specific and there are plenty of cases where you have to stand > on your head and count backwards to even make such a distinction. (For > example, with peering arrangements: you would have to factor out the > peering "service" into separate parts where you look at each part as a > directed provider/consumer aspect of the overall service.) The idea of having a producer/consumer, while common, is really not general enough. In an agreement both parties have obligations and both provide some form of service. Even if money is involved, that can flow in both directions, penalties. I believe the relationship should be 100% symmetric. I would alter the definition as below, but I'm ok with it as is. An agreement defines a dynamically-established and dynamically- managed relationship between two parties. The object of the relationship is the exchange of services between the parties within the context of the agreement. The management of this relationship is achieved by agreeing on the respective roles, rights and obligations of the parties. The agreement may specify not only functional properties for identification or creation of services, but also non- functional properties of the services such as performance or availability. Entities can dynamically establish and manage agreements via Web service interfaces. See https://forge.gridforum.org/projects/graap-wg for information about work being carried out by the OGF's Grid Resource Allocation Agreement Protocol (GRAAP) working group. > > > karl > > -- > Karl Czajkowski > karlcz(a)univa.com -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

2 1

GFS/RNS Session Slides uploaded
by Christopher Jordan 18 Jul '06

18 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 i've uploaded the slides for tomorrows GFS/RNS session at the OGSA F2F in Chicago to GridForge: https://forge.gridforum.org/sf/go/doc13666?nav=1 Hiro, can you run the Glance session for me tomorrow? I'll send a note if there are any further updates. Thanks. - ---------------------------------------------------- Chris Jordan HPC Systems Engineer High End Computing Systems Group San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEvDKTPCVtcXn6kg8RAtuhAKCX/jBW2GuIVSatPTl5FTBhePYumgCg2Azr D7izqv8j2HYQI/Mn14EPl/Q= =CWtq -----END PGP SIGNATURE-----

1 0

Basic Security Profile links
by Andreas Savva 17 Jul '06

17 Jul '06

These are the two profiles mentioned today: OGSA Basic Security Profile 1.0 - Core https://forge.gridforum.org/sf/go/doc13561?nav=1 OGSA Basic Security Profile 1.0 - Secure Channel https://forge.gridforum.org/sf/go/doc13560?nav=1

1 0

Meeting room for F2F at ANL
by Hiro Kishimoto 17 Jul '06

17 Jul '06

Hi all, We will have a meeting in building 211 at ANL campus. http://www.anl.gov/Visiting/anlemap.html If the meeting room is the same as the last time, it is C101 on the 2nd floor. The meeting will start 8:30am CDT. See you there, -- Hiro Kishimoto

2 3

F2F meeting materials
by Hiro Kishimoto 16 Jul '06

16 Jul '06

Hi all, For upcoming F2F meeting, we won't make any hard copies of meeting materials. Please upload your presentation and draft document to the following folder on GridForge in advance. Meeting Materials and Minutes > Interim Meetings > OGSA-15 - 2006 July Thanks and see you in Chicago, -- Hiro Kishimoto

1 0

Revised F2F meeting agenda for next week
by Hiro Kishimoto 15 Jul '06

15 Jul '06

Hi all, I've uploaded revised meeting agenda to GridForge. https://forge.gridforum.org/sf/go/doc13607?nav=1 Thank you for all session owners who provide their detailed agenda. Thanks and see you in Chicago! -- Hiro Kishimoto

1 0

OGSA Roadmap minutes, 7/12
by Christopher Jordan 14 Jul '06

14 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've uploaded the minutes of the OGSA Roadmap conference call on July 12th to GridForge. The document is available at: https://forge.gridforum.org/sf/go/doc13658?nav=1 Thanks. - ---------------------------------------------------- Chris Jordan HPC Systems Engineer High End Computing Systems Group San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEt8oPPCVtcXn6kg8RAgaGAJ93A+NJeo4w2x+NlKT1+rHF4yJqzACghSKO pvUQafkqoh8t3e9E7Dvkweo= =Xvn0 -----END PGP SIGNATURE-----

1 0

RE: [ogsa-wg] FINAL CALL: OGSA 1.5 Architecture and Glossary
by Subramaniam, Ravi 14 Jul '06

14 Jul '06

Hi David, I see what you are saying and I did consider that. The glossary term implied a "many to one" or "one to one" situation - one provider. What I was suggesting is a "one to many" situation which is very likely. So the situation where you have multiple providers accepting to an agreement (which at a higher level may be a single contract between domains) is still a "one to many" situation that the glossary term should cover. Right? Ravi -----Original Message----- From: David Snelling [mailto:David.Snelling@UK.Fujitsu.com] Sent: Thursday, July 13, 2006 4:14 AM To: Subramaniam, Ravi Cc: Andreas Savva; ogsa-wg Subject: Re: [ogsa-wg] FINAL CALL: OGSA 1.5 Architecture and Glossary Ravi, I think I would be happiest to leave this as a single bi-partite relationship. We have looked at this a lot in NextGRID, and even complex contracts (such as an EU project) actually boil down legally to a collection of contracts between two organizations, although they all sign a single document. On 12 Jul 2006, at 23:01, Subramaniam, Ravi wrote: > Hi Jem/Andreas, > > A quick comment: In the glossary#Agreement why is the object of the > relationship the delivery of a service by *only one* of the parties? > Couldn't it be "one or more" since there can be alternates for the > same > service, multipart agreements or aggregated services? It is possible > that GRAAP choose the single party to simplify the management of > agreements but this case is a subset of what the term can represent. > Agree? > > Thanks! > > Ravi > > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of > Andreas Savva > Sent: Tuesday, July 11, 2006 8:49 PM > To: 'ogsa-wg' > Subject: [ogsa-wg] FINAL CALL: OGSA 1.5 Architecture and Glossary > > Final drafts of the OGSA 1.5 documents ([Arch] and [Glossary]) are > available on Gridforge. These drafts were updated according to > comments > received and subsequent teleconference reviews. The drafts are > change-tracked relative to the previous draft versions. > > Please comment on the list, this Thursday's call, or at the F2F next > week. The plan is to submit back to the GGF Editor > *after the end of the Interim Meeting next week, July 20 (Thursday).* > > [Arch] > https://forge.gridforum.org/sf/go/doc13553?nav=1 > > [Glossary] > https://forge.gridforum.org/sf/go/doc13555?nav=1 > > -- > Andreas Savva > Fujitsu Laboratories Ltd > -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

3 2

Teleconference minutes - 13 July 2006
by Andreas Savva 14 Jul '06

14 Jul '06

https://forge.gridforum.org/sf/go/doc13654?nav=1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 13 July 2006 ================================== * Participants Dave Berry (NeSC) Michel Drescher (Fujitsu) Andrew Grimshaw (UVa) Chris Jordan (SDSC) Hiro Kishimoto (Fujitsu) Andreas Savva (Fujitsu) Ellen Stokes (IBM) Jun Tatemura (Hitachi) Jay Unger (IBM) Pete Ziu (Northorp Grumman) Minutes: Andreas Savva * July 10 minutes approved with no changes * Action items review [Only items with updates are listed below.] - Hiro & Andreas to look into re-arranging the F2F Monday and Tuesday morning sessions. - Reviewed on this call. Closed. - EMS team (Steven, Andreas, Donal) to review data staging scenario (section 5 of https://forge.gridforum.org/sf/go/doc13591?nav=1 ) Bring to people's attention again at the next EMS call. (postpone until June 29) - Donal commented on the list. - The topic will reviewed in the Data session at the next F2F. Closed. * July F2F update Reviewed Hiro's proposed agenda. Accepted it with one minor change: - Swap GFS and Naming sessions -- Naming should come first since Andrew has to leave mid-afternoon Tuesday. 'Official' Dinner: - Some people are leaving as early as Tuesday so the first choice is Monday, with Tuesday in second place. * GGF18 - F2F on Friday 9/15 update - Jay has booked a room in an IBM facility within walking distance from the GGF18 hotel (5 blocks). - It is a secure facility and attendees names have to given at least 48 hours in advance. - The room can hold 22 people and has a network connection. - Agreed to pick the IBM facility due to its location -- close to the hotel. (Northorp Grumman location would have required a tube ride). * CDDLM update - Jun will review and correct Hiro's CDL by the F2F session - The post deployment CDL can be retrieved by invoking an operation on 'system' (query using xpath). - Jun will provide the name of the operation and a simple example document showing executable, environment variables. - Hiro will make some minor changes to the sequences to incorporate the above data by the Thursday review. * Basic Security Profile PC review - postponed

1 0

RE: [ogsa-wg] FINAL CALL: OGSA 1.5 Architecture and Glossary
by Subramaniam, Ravi 13 Jul '06

13 Jul '06

Hi Jem/Andreas, A quick comment: In the glossary#Agreement why is the object of the relationship the delivery of a service by *only one* of the parties? Couldn't it be "one or more" since there can be alternates for the same service, multipart agreements or aggregated services? It is possible that GRAAP choose the single party to simplify the management of agreements but this case is a subset of what the term can represent. Agree? Thanks! Ravi -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andreas Savva Sent: Tuesday, July 11, 2006 8:49 PM To: 'ogsa-wg' Subject: [ogsa-wg] FINAL CALL: OGSA 1.5 Architecture and Glossary Final drafts of the OGSA 1.5 documents ([Arch] and [Glossary]) are available on Gridforge. These drafts were updated according to comments received and subsequent teleconference reviews. The drafts are change-tracked relative to the previous draft versions. Please comment on the list, this Thursday's call, or at the F2F next week. The plan is to submit back to the GGF Editor *after the end of the Interim Meeting next week, July 20 (Thursday).* [Arch] https://forge.gridforum.org/sf/go/doc13553?nav=1 [Glossary] https://forge.gridforum.org/sf/go/doc13555?nav=1 -- Andreas Savva Fujitsu Laboratories Ltd

2 1

RE: [ogsa-wg] FINAL CALL: OGSA 1.5 Architecture and Glossary
by Dave Berry 13 Jul '06

13 Jul '06

The Glossary has the following definition of "endpoint": "Endpoint: A Web Service endpoint to which a client may bind in order to consume a service." So an endpoint is an endpoint. Hmm. Actually, there is a reference to the detailed definition given by the W3C so this entry isn't as circular as it first seems. I still think the phrasing could be improved. Also, to be really petty, the W3C term is "end point" (with a space). How about: "Endpoint: A specific location to which a client may bind in order to access a Web Service, using a specific protocol and data format." Dave. P.S. I should add that I find the Glossary to be a very helpful document. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andreas Savva Sent: 12 July 2006 04:49 To: 'ogsa-wg' Subject: [ogsa-wg] FINAL CALL: OGSA 1.5 Architecture and Glossary Final drafts of the OGSA 1.5 documents ([Arch] and [Glossary]) are available on Gridforge. These drafts were updated according to comments received and subsequent teleconference reviews. The drafts are change-tracked relative to the previous draft versions. Please comment on the list, this Thursday's call, or at the F2F next week. The plan is to submit back to the GGF Editor *after the end of the Interim Meeting next week, July 20 (Thursday).* [Arch] https://forge.gridforum.org/sf/go/doc13553?nav=1 [Glossary] https://forge.gridforum.org/sf/go/doc13555?nav=1 -- Andreas Savva Fujitsu Laboratories Ltd

1 0

Current drafts of OGSA Data documents
by Dave Berry 12 Jul '06

12 Jul '06

Dear OGSA WG, The current drafts of the OGSA Data Architecture and OGSA Data Services documents can be found at https://forge.gridforum.org/sf/go/doc13635?nav=1 and https://forge.gridforum.org/sf/go/doc13605?nav=1. We will discuss these during the Data session of next week's F2F meeting, on Monday morning. Best wishes, Dave Berry Deputy Director, Research & E-infrastructure Development National e-Science Centre, 15 South College Street Edinburgh, EH8 9AA +44 131 651 4039

1 0

RE: [ogsa-wg] Proposed agenda for July 13th call
by Dave Berry 12 Jul '06

12 Jul '06

Thanks Donal. A couple of comments: > I think that what would be far more useful would be to merge > this with some of the EMS scenarios to form a combined OGSA > Parameter Space Exploration use-case. But that's a lot of > work to do since it looks like the compute and the data people > are failing to see eye-to-eye (again). If we are failing to see eye-to-eye, that's an argument for making this use case (and other similar ones) a high priority for both compute and data people. I hope we can address some of these issues on Monday. > I believe that some of the things I've been thinking about for the > EPS spec are likely to be useful in the selection of Data-related > resources. All that changes really (at the interface level) are the > input request language and the candidate description language. This seems entirely plausible. Our Data Architecture document makes the point that services such as deployment, reservation, scheduling etc. should be generic enough to handle many different types of resources (including computation, data & network). Although I do know of people in the data world who believe that some of the issues are substantially different for computation & data; perhaps it would be sensible to arrange a brainstorming meeting on this topic. > Service instances are chosen (including any deployment) before the > commencement of the scenario. A question they don't address is > whether moving the computation to the data would be better. This is just one scenario; we could develop another where the computation is moved to the data. From our point of view, when the instances are chosen is of little interest, provided the deployment is managed as necessary. > There is a post-processing phase to be applied to the output data > which the scenario does not properly highlight. We'd be happy to correct this. > A more sensible structure might involve some kind of Orchestration > service (e.g. based on workflows) to control the > parameterized input data creation I believe a later version of this scenario does suggest the use of workflows. We'd be happy to work more closely on this. Best wishes, Dave.

1 0

Proposed agenda for July 13th call
by Hiro Kishimoto 12 Jul '06

12 Jul '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on July 13th Thursday from 8:30am - 10:30am (CDT). Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0713 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (July 10) - https://forge.gridforum.org/sf/go/doc13651?nav=1 Action Items status review (see the bottom of this email) Agenda bashing 2) July F2F meeting update (Hiro and Andreas, 30 min) > - Ellen has a conflict most of Monday since she has to attend a DMTF > TC meeting. She can be available only between 8:30-10:30am on > Monday. > - There are only a few possibilities since many people (Jay, Dave, > Andrew, etc) will not be available Tuesday afternoon and > Wednesday, and there are people dialling in from Europe for the > morning sessions. > > Plan is to confirm schedule on Thursday's call, including other > logistics. Meeting agenda for the F2F meeting. - https://forge.gridforum.org/sf/go/doc13607?nav=1 3) Basic Security Profile Public Comments review (Takuya, 30 min) Takuya will send out proposed BSP text change before the call 4) CDDLM & EMS joint discussion (If Jun is available) Jun will send out revised material before the call. 5) Wrap up (10 min) AOB <*NEXT CALL*> July 17-20: F2F meeting in Chicago (ANL) Telecon schedule on wiki: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.ogsa-wg/wiki/Telec… <*ACTION ITEMS*> > From July 10 call - Hiro & Andreas to look into re-arranging the F2F Monday and Tuesday morning sessions. > From June 29 call - Hiro to also make any relevant updates to the Scenarios text - Jun/Hiro to also prepare the post-deployment BLAST CDL document > From June 12 call - Jun will correct the CDL XML examples written by Hiro. > From June 8 call - EMS team (Steven, Andreas, Donal) to review data staging scenario (section 5 of https://forge.gridforum.org/sf/go/doc13591?nav=1 ) Bring to people's attention again at the next EMS call. (postpone until June 29) > From May 22 call - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches (postpone until July 10) - Waiting for Jay to get additional material - Waiting for Marvin's proposal -- Hiro Kishimoto

2 2

FINAL CALL: OGSA 1.5 Architecture and Glossary
by Andreas Savva 12 Jul '06

12 Jul '06

Final drafts of the OGSA 1.5 documents ([Arch] and [Glossary]) are available on Gridforge. These drafts were updated according to comments received and subsequent teleconference reviews. The drafts are change-tracked relative to the previous draft versions. Please comment on the list, this Thursday's call, or at the F2F next week. The plan is to submit back to the GGF Editor *after the end of the Interim Meeting next week, July 20 (Thursday).* [Arch] https://forge.gridforum.org/sf/go/doc13553?nav=1 [Glossary] https://forge.gridforum.org/sf/go/doc13555?nav=1 -- Andreas Savva Fujitsu Laboratories Ltd

1 0

Version 7 of the information modeling guidelines
by Fred Maciel 12 Jul '06

12 Jul '06

Hi, Here is a new version (v7) of the modeling guidelines document. I'm hoping to receive comments on it at the F2F (I'll be participating by phone on Monday). Last time this document was scheduled to be reviewed nobody had read it, the document changes in this version reflect the changes in the last two versions. https://forge.gridforum.org/sf/go/doc12798?nav=1 Regards, Fred Maciel Hitachi America R&D

1 0

Teleconference minutes - 10 July 2006
by Andreas Savva 11 Jul '06

11 Jul '06

https://forge.gridforum.org/sf/go/doc13651?nav=1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 10 July 2006 ================================== * Participants Pete Ziu (Northrop Grumman) Jay Unger (IBM) Jem Treadwell (HP) Ellen Stokes (IBM) Andreas Savva (Fujitsu) Mark Morgan (UVa) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Chris Jordan (SDSC) * June 29 minutes approved with no changes * July 6 minutes approved with no changes * Action review [Only items with updates are listed.] ** Jay will look into getting a room at downtown D.C. for the B2B F2F after GGF18 - Sent room request; waiting for reply - Do not know if facilities have internet connection ** Hiro will ask Pete Ziu to check if it is possible to reserve a room at Northrop Grumman for the B2B F2F after GGF18 - Sent room request; waiting for reply. - Do not know if facilities have internet connection ** Hiro will send out an email outlining the proposal and aim to confirm it on the next call - Hiro submitted a request for 4 sessions. Closed. ** Andreas to upload the sequence diagrams to Gridforge. - This was closed last time. * OGSA-15: F2F session update - Ellen has a conflict most of Monday since she has to attend a DMTF TC meeting. She can be available only between 8:30-10:30am on Monday. - There are only a few possibilities since many people (Jay, Dave, Andrew, etc) will not be available Tuesday afternoon and Wednesday, and there are people dialling in from Europe for the morning sessions. ACTION: Hiro & Andreas will look into re-arranging the Monday and Tuesday morning sessions. Plan is to confirm schedule on Thursday's call, including other logistics. * Information model discussion - Jay has talked with a number of people (Andrew, Chris). There is no write up from Miron. - If there is agreement (seems likely) that the internal representation of both a schema-based approach and a schema-less approach will or can be the same the question is whether there is anything that can be expressed with the second approach that cannot be expressed with the first. Jay claimed that Ellen's hierarchical (Resource, capability) rendering example has such a feature. Other people disagreed. - This discussion will continue at the F2F. ACTION: Jay will provide a document summarizing the advantages of the schema-less approach for discussion at the F2F. * Roadmap update Chris Jordan gave an update on the Roadmap activities: - Bi-weekly conference calls have been started with a small core group. Next call this Wednesday. - Reviewing trackers this week - Will be contacting persons that can provide Roadmap entries - Mike Behrens wil be writing up a short document on underlying WS standards - The Introduction will be re-written to de-link it from other document publications since the Roadmap will be published periodically and should therefore stand alone. - Have started a wiki space (blank page at the moment). * Security discussion: Postponed to Thursday & conditional on progress * CDDLM & EMS: Postponed to Thursday & conditional on progress

1 0

OGSA Roadmap Editors call, 7/12
by Christopher Jordan 11 Jul '06

11 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The next roadmap editors call will be this Wednesday at 3PM PDT - 6PM EDT - 7AM 7/13 Japan time. Here are the call-in details: Host: Christopher Jordan Meeting Title: OGSA Roadmap Editing Meeting Date: July 12, 2006 03:00 PM [Pacific Time] To Join Audio Conference Primary Dial-In: 1 (877) 213-2541 Alternate Dial-In: 1 (630) 424-7813 Passcode: 7035408# Proposed Agenda: 1. Roll call/Note taker assignment 2. Agenda Bashing 3. Action Items report Status report from Chris and Mike on section rewrites/new material drafts Update from Dona on "contact tracker" wiki 4. Discussion Topics Review of all Tracker Items Discussion of "Gap Analysis" Discussion of OGF relationship to OGSA process - any changes? Discussion of Information Model/Information Management in OGSA 5. AOB - ---------------------------------------------------- Chris Jordan HPC Systems Engineer High End Computing Systems Group San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEsxsHPCVtcXn6kg8RAlGBAKDn/8ZHOpruYmY/aN/FxSZ1T7iqEgCgo0C5 nDJAEm5yTqPB0UBs3mmCgBI= =jSBL -----END PGP SIGNATURE-----

1 0

Member list wiki page
by Hiro Kishimoto 11 Jul '06

11 Jul '06

Hi Pete, Per your request, I've created a wiki page listing up current WG members. https://forge.gridforum.org/sf/wiki/do/viewPage/projects.ogsa-wg/wiki/Membe… As we discussed at the call, member list was available for everyone on the old GridForge. But on the new GridForge, only administrator see the list. Thanks, -- Hiro Kishimoto

1 0

Fw: info model XML representation
by Ellen Stokes 10 Jul '06

10 Jul '06

Feedback from the GLUE schema person I've been working with...to factor into our info model discussions. Appears additional collaboration with Sergio is welcome. Ellen Ellen Stokes STSM, Grid Computing TC Member, IBM Academy of Technology Austin, Texas tl 678 0552 outside +1 512 838 0552 stokese(a)us.ibm.com ----- Forwarded by Ellen Stokes/Austin/IBM on 07/10/2006 04:11 PM ----- Sergio Andreozzi <sergio.andreozzi(a)cnaf.infn.it> 06/20/2006 08:16 AM To Ellen Stokes/Austin/IBM@IBMUS cc Laurence Field <Laurence.Field(a)cern.ch> Subject Re: info model XML representation Dear Ellen, I read the document and found it interesting. As regards the main question (which of the two proposal is preferred), I have not a clear answer yet since this depends on the final goal of the paper. Below you can find my considerations: Some preliminary statement: 1. the GLUE Schema models Grid resource characteristics 2. the JDL is used to describe a job request; requirements on resources can be expressed based on GLUE Schema-related attributes 3. JSDL models a job description, hence it contains requirements on resource characteristics; the requirements are expressed over a set of characteristics inspired by CIM; this set of attributes can be "isolated" in a Resource Requirement Language (RRL) so the proportion: JSD : JSDL = GLUE Schema : RRL The document describes a solution to both model resource characteristics and requirements on resources. In order to better position the paper, it would be useful to state: 1. relationship between the proposal for describing resource requirements and the JSDL Resources Elements; Figure 1 can help in understanding, nevertheless it would be better to write it more explicitly 2. better state the goal of the modeling, in the sense that it should be more clear if the purpose of the document is to describe a modeling for enabling a resource selection process; (also in the abstract); a possible discussion on the matchmaking approaches using this modeling could also fit the paper; 3. it is generally more acceptable to write about "a Grid" or "the Grids" instead of "the grid", since there is no a unique Grid as it was envisioned in the early years of this paradigm 4. about the two possible approaches, at a first glance, I do not lean to a particular approach; some comments below: Proposal I - Using XML typing and extensibility pro: * enables better data quality enforcement since it relies on XML Schema data model * characteristics modeled as XML elements (instead of attributes) give more flexibility in defining complex type neutral: there is no a symmetric approach in the description of resources and activities consideration about the node entity; considering the GLUE Schema experience: - resources are managed by batch systems and are organized in pools exposed to the Grid layer - for scalability reasons, there is no description of single nodes, but description of homogeneous set of nodes, i.e., homogeneous execution environments for applications; this implies that only static characteristics are modeled and advertised (e.g., TotalMainMemory is ok, FreeMainMemory is ko); dynamic attributes can be added if they refer to aggregation (e.g., MaxFreeMainMemory, that is the highest free main memory among the nodes present) - an important aspect is the service differentiation, that is, do all Grid users have the same possibility to access a resource or not? this is currently a hot topic and the solutions being investigated adopt the creation of different shares/priorities assignable to different groups/roles hold by users; this means that the resources are the same, but the selection process should be able to consider the QoS aspect; these aspects are important in a resource selection process Proposal II - Using typing outside of XML this approach is schema-free and symmetric (a la ClassAd); One more general comment. An important requirement for a selection system is to be able to express preferences that are used to choose the best resource among the available ones that matched the hard-constraints. This topic was the core of my PhD thesis that you might be interested looking at: ( http://www.cs.unibo.it/pub/TR/UBLCS/ABSTRACTS/2006.bib?ncstrl.cabernet//BOL… ) For resource description, the undertaken approach is close to your proposal I; for requirements and preferences, I've defined a tailored language inspired by XQuery (it is called XMatch). I would like to have your feedback about these considerations. Consider also the possibility of writing a joint paper. Cheers, Sergio Laurence Field wrote: > Hi Ellen, > > I think that Sergio is the correct person to comment on this. I have > cc'd him, > > Laurence > > Ellen Stokes wrote: > >> >> Laurence, >> >> As part of the information model direction that the resource >> management design team is pulling together (part of the GGF OGSA >> workgroup), we are considering 2 alternatives for the XML >> representation of an information model. We've discussed the pros and >> cons of each proposal, but have come to no conclusions or >> recommendations. So, we've decided to solicit the opinions of groups >> that use information models and have an XML representation. And the >> EGEE's G-lite work is one such group. >> I'm not sure if you're the right person to work with to solicit an >> opinion on XML representation. If not, please let me know who I >> should talk with. >> >> I've attached the document. Section 3 proposes the overall direction >> for modeling resources in the grid. Section 4 provides an example >> (take the example at face value - it's just an example so don't worry >> about details of the reousrces modeled) and proposes 2 alternative XML >> representations. I'd like to understand G-lite's opinion on which >> representation should be used to model resources in the grid and why. >> >> >> >> Thanks. >> Ellen >> >> Ellen Stokes >> STSM, Grid Computing >> TC Member, IBM Academy of Technology >> Austin, Texas >> tl 678 0552 outside +1 512 838 0552 >> stokese(a)us.ibm.com > > -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 0

Update on OGSA HPC Profile WG (incl. LAST CALL on use-case doc)
by Marty Humphrey 10 Jul '06

10 Jul '06

Cross-posting, as per Hiro's request... -----Original Message----- From: owner-ogsa-hpcp-wg(a)ggf.org [mailto:owner-ogsa-hpcp-wg@ggf.org] On Behalf Of Marty Humphrey Sent: Monday, July 10, 2006 7:39 AM To: ogsa-hpcp-wg(a)ggf.org Cc: 'Marty Humphrey' Subject: [ogsa-hpcp-wg] Update on OGSA HPC Profile WG (incl. LAST CALL on use-case doc) Folks, As the OGSA F2F is next week, Marvin and I thought it would a good time to recap our group's progress to date. At GGF17 in Tokyo, we outlined three deliverables for the group: OGSA HPC Use Cases (GFD-I; first draft: Apr 2006, ready for public comments: July 2006), OGSA HPC profile specification (GFD-R.P; first draft: Aug 2006; ready for public comments: Nov 2006), and OGSA HPC initial common cases extension profile specification (GFD-R.P; first draft: Jan 2007; ready for public comments: Apr 2007). The OGSA HPC Use Cases document was discussed extensively this Spring, so we'd like to issue a "LAST CALL" on this document, which has recently been reformatted to GGF specification: https://forge.gridforum.org/sf/go/doc13649?nav=1 . Comments must be made by of 7/17/06 to be reflected in the document that will go into the "public comments" area of GGF (of course, you are free to make comments during the official GGF "public comments" as well -- this "LAST CALL" is being made to the WG). Our OGSA HPC Profile group has been VERY active (the OGSA HPC Profile email list has not been used to date -- all of the activity is taking place in the JSDL and BES working groups, both on the email lists and in the conference calls). We believe that we are making great progress on making sure that our requirements are contained in the current BES draft and being addressed in the next JSDL draft). At this time, we believe that we are on-track to make the Aug 2006 "first draft" deadline for the OGSA HPC profile specification, although much work remains. At the OGSA F2F next week, the topics that we anticipate discussing include BES, JSDL, the issue of "rendering" (e.g., WSRF, WS-I), and the information model. We have made a request to have a single 90-minute session at GGF18 in Wash DC in September. We believe that the majority of this time will be used to discuss our WG's forthcoming initial draft of the OGSA HPC profile specification. Thanks to everyone for participating on the BES and JSDL discussions! We're very happy with our group's progress to date! -- Marty Marty Humphrey Assistant Professor Department of Computer Science University of Virginia

1 0

OGSA Roadmap call minutes uploaded
by Christopher Jordan 10 Jul '06

10 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've uploaded the minutes of the last OGSA Editors call, on June 28th, to GridForge. They are available at https://forge.gridforum.org/ sf/go/doc13650?nav=1, or in the normal place you go for all your OGSA telcon minutes. Andreas and Hiro - I think I put it in the appropriate place this time. Let me know if I missed anything. - ---------------------------------------------------- Chris Jordan HPC Systems Engineer High End Computing Systems Group San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEsmG0PCVtcXn6kg8RAl1nAKCPit7eMsijHgYrFjlkR4zHLll93wCfQOgI EgShVg5+/Unim1VV4bbkpBM= =oEb/ -----END PGP SIGNATURE-----

2 1

Proposed agenda for July 10th call
by Hiro Kishimoto 10 Jul '06

10 Jul '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on July 10th Monday from 5pm to 7pm (CDT). I am sorry, I cannot follow the 48H rule this time. The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0710 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (June 29 & July 6) - https://forge.gridforum.org/sf/go/doc13636?nav=1 - https://forge.gridforum.org/sf/go/doc13645?nav=1 Action Items status review (see the bottom of this email) Agenda bashing 2) Information model (Ellen and Fred, 30 min) > - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) > to get feedback on pros / cons of the two rendering approaches > (postpone until June 19); and > > - Jay has talked with Miron. There is no written material ready > yet. > - People interested in this topic were asked to come to the OGSA > call. You can download current material from here; - Information Modeling in OGSA - Position Paper https://forge.gridforum.org/sf/go/doc13073?nav=1 - BES Information Model https://forge.gridforum.org/sf/go/doc13074?nav=1 - Guidelines on information modeling for OGSA https://forge.gridforum.org/sf/go/doc12798?nav=1 3) Roadmap 1.1 (ChrisJ and Dona, 30 min) Chris will report out the status of the roadmap team. He also explain a couple of open issues and ask OGSA-WG at-large for feedbacks. 4) Security & BSP Public Comments review (Frank and Takuya, 20 min) Frank said: > The internal authz call-out interface discussion has so far yielded 23 > email messages in the last couple of days among David, Von and myself > without any clear decisive stated direction yet - please bear with us > while we struggle to find the right PATH. Takuya will send out proposed BSP text change before the call 5) CDDLM & EMS joint discussion (Jun and Hiro, 20 min) Jun will send out revised material before the call. 6) Wrap up AOB <*NEXT CALL*> July 13 (Thu): F2F prep (Tom and Hiro) July 17-20: F2F meeting in Chicago (ANL) Telecon schedule on wiki: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.ogsa-wg/wiki/Telec… <*ACTION ITEMS*> > From July 6 call - Jay will look into getting a room at downtown D.C. for the B2B F2F after GGF18 - Hiro will ask Pete Ziu to check if it is possible to reserve a room at Northrop Grumman for the B2B F2F after GGF18 > From June 29 call - Hiro will send out an email outlining the proposal and aim to confirm it on the next call - Hiro to also make any relevant updates to the Scenarios text - Jun/Hiro to also prepare the post-deployment BLAST CDL document - Andreas to upload the sequence diagrams to Gridforge. > From June 12 call - Jun will correct the CDL XML examples written by Hiro. > From June 8 call - EMS team (Steven, Andreas, Donal) to review data staging scenario (section 5 of https://forge.gridforum.org/sf/go/doc13591?nav=1 ) Bring to people's attention again at the next EMS call. (postpone until June 29) > From May 22 call - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches (postpone until July 10) - Waiting for Jay to get additional material - Waiting for Marvin's proposal -- Hiro Kishimoto

2 3

Teleconference minutes - 6 July 2006
by Andreas Savva 07 Jul '06

07 Jul '06

Attached. https://forge.gridforum.org/sf/go/doc13645?nav=1 -- Andreas Savva OGSA Teleconference - 6 July 2006 ================================= * Participants Mike Behrens (R2AD, LLC) Michel Drescher (Fujitsu) Hiro Kishimoto (Fujitsu) Andreas Savva (Fujitsu) Jem Treadwell (HP) Jay Unger (IBM) Minutes: Andreas Savva * Summary of new actions ACTION: Jay will look into getting a room at downtown D.C. for the B2B F2F after GGF18 ACTION: Hiro will ask Pete Ziu to check if it is possible to reserve a room at Northrop Grumman for the B2B F2F after GGF18 * June 29 minutes approval postponed; no quorum * Action item review - Hiro will send out an email outlining the GGF18 proposal and aim to confirm it on the next call - GGF18 proposal not sent out yet. Hiro will send it out to the list and concurrently request the four sessions that the group talked about on a previous call. - Postponed decision for a back-to-back meeting GGF18 (Friday) until the July F2F. Potential hosts are Northrop Grumman or IBM. ACTION: Jay will look into getting a room at downtown D.C. for the B2B F2F after GGF18 ACTION: Hiro will ask Pete Ziu to check if it is possible to reserve a room at Northrop Grumman for the B2B F2F after GGF18 - Hiro to ask Jun and Dejan to check the CDL documents - Waiting for feedback from Dejan/Jun - Hiro to also make any relevant updates to the Scenarios text - Not urgent and since the Scenarios draft is now in flux it is ok to postpone it until the F2F - Jun/Hiro to also prepare the post-deployment BLAST CDL document - There was a discussion of this at the April F2F and Jun had shown some samples that could be used as a base. - Andreas to upload the sequence diagrams to Gridforge. - URL sent out by email. Closed. - Agreed that action items that become obsolete should be dropped from the list. - Closed the last four on the action list (Compliance and three deferred ones) as obsolete. * July F2F update - Agreed to take one hour at the end of the EMS session on Thursday to discuss Geoffrey Fox's comments on OGSA. - Also arrange an informal discussion (smaller group) before Wednesday. * EMS Architecture review - No objections to overall structure and outlined content. A revised first draft with better drafted content will be available at the F2F. - Make sure that sequences focus only on their specific topic and clearly show how they build on each other. * OGSA 1.5 review - Andreas had updated the Intellectual rights & Copyright statement at the back but it needs some further corrections. (Andreas) - Naming policy statement needs more explanation. It assumes that the reader has knowledge of WS-Naming and what 'profiled usage' is. Also it looks normative but it does not use normative terminology and so may be confusing. It is not clear how (not stated that) the statements build on each other. - Jem will send a proposed revision to Andreas - WSDM 1.1 is going to vote for OASIS Standard, should the WSDM reference document be updated? It is not critical. Keep it as is. - (tm) and (sm) usage: Re-affirmed that for now, first use is ok and try to make sure that it is used as an adjective. But it is not a showstopper and this document does not have to wait until the guidelines are clarified. - Agreed to discuss general (tm) (sm) usage guidelines at the F2F.

1 0

Proposed agenda for July 6th call
by Hiro Kishimoto 06 Jul '06

06 Jul '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on July 6th Thursday from 8:30am - 10:30am (CDT). Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0706 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (June 29th) - https://forge.gridforum.org/sf/go/doc13636?nav=1 Action Items status review (see the bottom of this email) Agenda bashing 2) July F2F update (Hiro 20 min) Andreas is asking a one-hour slot to discuss Geoffrey Fox's comments on OGSA and our replies to him. There is a tracker on gridforge. http://forge.gridforum.org/sf/tracker/do/listArtifacts/projects.ogsa-wg/tra… Dave and Jay are two people who should be present. This rules out Tuesday afternoon and Wednesday. Also Monday and Tuesday morning are already pretty full. So it looks like this may end up on Thursday after the EMS session. The alternative is a working lunch. 3) revised EMS Arch scenario document review (Andreas 20 min) > Andreas will also prepare a revised EMS Scenarios document for the > next call. 4) Wrap up (10 min) AOB <*NEXT CALL*> July 10 (Mon): Information model (Ellen and Fred) Roadmap 1.1 (Hiro, ChrisJ, and Jem) Security & BSP Public Comments review (Frank and Takuya) CDDLM & EMS (Jun and Hiro) July 13 (Thu): F2F prep (Tom and Hiro) July 17-20: F2F meeting in Chicago (ANL) Telecon schedule on wiki: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.ogsa-wg/wiki/Telec… <*ACTION ITEMS*> > From June 29 call - Hiro will send out an email outlining the proposal and aim to confirm it on the next call - Hiro to ask Jun and Dejan to check the CDL documents - Hiro to also make any relevant updates to the Scenarios text - Jun/Hiro to also prepare the post-deployment BLAST CDL document - Andreas to upload the sequence diagrams to Gridforge. > From June 26 call - Hiro to confirm contact with (ex-)EGA TC > From June 12 call - Jun will correct the CDL XML examples written by Hiro. > From June 8 call - EMS team (Steven, Andreas, Donal) to review data staging scenario (section 5 of https://forge.gridforum.org/sf/go/doc13591?nav=1 ) Bring to people's attention again at the next EMS call. (postpone until June 29) > From May 22 call - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches (postpone until July 10) - Waiting for Jay to get additional material - Waiting for Marvin's proposal > From April 5 F2F meeting - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. Deferred - Frank to write up and send to the list a one page summary of the authorization call-out proposal. (April 24 call, postpone until June 14) - Jay check and find out relatively small funding to Globus to develop document on their security work (April 6 F2F) - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (April 4 F2F) -- Hiro Kishimoto

2 1

No call on July 3rd
by Hiro Kishimoto 04 Jul '06

04 Jul '06

Hi all, Since July 4th is US holiday (Independence day), we have no call on July 3rd. Next call is July 6th Thursday. <*NEXT CALL*> July 6 (Thu): EMS scenarios (Steven and Andreas) July 10 (Mon): Information model (Ellen and Fred) Roadmap 1.1 (Hiro, ChrisJ, and Jem) Security & BSP Public Comments review (Frank and Takuya) CDDLM & EMS (Jun and Hiro) July 13 (Thu): F2F prep (Tom and Hiro) July 17-20: F2F meeting in Chicago (ANL) Enjoy your holiday! -- Hiro Kishimoto

2 1

Teleconference minutes - 29 June 2006
by Andreas Savva 30 Jun '06

30 Jun '06

Minutes attached. https://forge.gridforum.org/sf/go/doc13636?nav=1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 29 June 2006 ================================== * Participants Andreas Savva (Fujitsu) Darren Pulsipher (EMC) Steven Newhouse (OMII) Takuya Mori (NEC) Mark Morgan (UVa) Tom Maguire (EMC) Hiro Kishimoto (Fujitsu) Chris Jordan (SDSC) Donal Fellows (UoM) Minutes: Andreas Savva * June 22 minutes approved with no changes * June 26 minutes approved with no changes * Action review - Hiro to confirm contact with (ex-)EGA TC - Explained action background: look into holding a session to investigate how the EGA reference model fits with OGSA now that GGF and EGA have merged. - This would also be interesting for the Roadmap - Add sequence diagrams to the scenarios: (postpone until June 29) - Andreas will do the "Install application" scenario (3.1) - Mike will do the "Install application using ACS" scenario (3.3) - Other volunteers welcome. (Andreas will ask Donal for the EPS scenario) - Andreas has started doing the sequence diagrams in RSM - Darren volunteered to help out - Review again at the next EMS call (June 29) - Andreas will merge draft scenarios and sequence diagrams to the "EMS Architecture Scenarios" document (postpone until June 29) - Both of these actions are in progress and their status reviewed during this call. [It is ok to close both since the actions activities listed are part of the document preparation and are reviewed separately.] - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches (postpone until June 19) - Waiting for Jay to get additional material - Waiting for Marvin's proposal - Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well (postpone until June 19) - It was discussed on a call a few weeks ago and the group is in a wait-and-see state on this issue. Not clear what is new or better with this rendering proposal. - The overall activity is driven by the previous action. Closed. * Security discussion postponed * GGF18 sessions review - Groups get automatic approval if up to 2 sessions - Last call the proposal was for four so AD approval would be needed. - Possible F2F for the Friday. The venue is not fixed yet ACTION: Hiro will send out an email outlining the proposal and aim to confirm it on the next call * CDL documents review Hiro produced and sent out new versions of the CDL documents. A few remaining issues were discussed. - Location of application binary (to deploy from) and format. Agreed that in general the client would not know these (but may know under certain circumstances). So in general - deployer (or perhaps developer) produces (original) CDL - Client produces jsdl - And a repository or some other internal component keeps track of binaries and related information - Permission and Owner of files. - The binary does not have to be owned by the user running the job; user just needs to be able to execute. - Simplest case assume that the correct permissions/ownership are set in the archive - If the desire is to show it as an example in the CDL something like "root.bin 755" or perhaps "blast.blast 755" or 555 is appropriate. - These are also affected by system policy. - pre-script - Hiro has talked with Chris Smith and they have removed the pre-script. - Assume instead that the db is pre-formatted (perhaps by an earlier user job) and that it can be made available by requesting a specific filesystem be made available on the host. - Hiro added 'database' filesystem. ACTION: Hiro to ask Jun and Dejan to check the CDL documents ACTION: Hiro to also make any relevant updates to the Scenarios text ACTION: Jun/Hiro to also prepare the post-deployment BLAST CDL document * EMS Scenarios review Andreas sent out sequence diagrams produced by RSM. It includes a couple of the early scenarios (Direct and Indirect Job execution) and the "Deploy an application" scenario. This sequence diagram is based fairly closely to the text reviewed in earlier calls. Did a walkthrough of the Deploy scenario: - There are too many call outs to generic Information Services. These should be abbreviated in this scenario and expanded and made more concrete in others, e.g., the ACS or EPS scenarios. - Hiro's CDL does not allow the JM to change anything (and hostname is part of the deployment API). Need to look into this further. In any case it is important to also have an example of a post-deployment CDL document. (See action above) - There is a small mismatch between what the scenario describes as the interaction with the deployment service and what CDDLM seems to expect. Need to decide whether the scenarios should show the JM driving the interaction with CDDLM directly or whether there is a deployment service that does it. The next steps are to do the EPS sequence and the ACS sequence. ACTION: Andreas will send the EMS Model exported from RSM to Darren (done) ACTION: Donal will sent out the link to the draft EPS document (done) ACTION: Andreas to upload the sequence diagrams to Gridforge. Andreas will also prepare a revised EMS Scenarios document for the next call.

1 0

CDL document for BLAST
by Hiro Kishimoto 29 Jun '06

29 Jun '06

Hi all, The following is my write up for CDL document for BLAST application based on the dialogue with Chris Smith. So far, I guess we will translate JSDL document to CDL document or extract necessary information from JSDL document and put them into CDL document. However JSDL document does not have a couple of information we need for CDL. (1) Application binary source location and its archive format. (2) File permission on the target server. We can add such necessary information into the JSDL document as extensions. For (2), we can assume default value (e.g. 755). Another possibility is we expect client tooling produce both JSDL document and CDL document at the same time. Advantage of this option is the tooling can guarantee consistency between JSDL document and CDL document. Chris and I agree this is reasonable scenario as our first step. Regarding to BLAST database, we expect client must run prep-job to format BLAST database and BLAST job should mount such formatted database before BLAST run. Formatted database should be reside e.g. /db/ncbiblast/est which should be mounted before BLAST run. The attached files are revised JSDL and CDL documents for review. I value your feedback. -- Hiro Kishimoto

1 0

Proposed agenda for June 29th call
by Hiro Kishimoto 28 Jun '06

28 Jun '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on June 29th. Thursday from 8:30am - 10:30am (CDT). Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0629 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (June 22 & 29) - https://forge.gridforum.org/sf/go/doc13624?nav=1 - https://forge.gridforum.org/sf/go/doc13628?nav=1 Action Items status review (see the bottom of this email) July F2F and GGF18 plan update (if any) Agenda bashing 2) CDDLM & EMS joint discussion (Jun and Hiro, 30 min) Jun and Hiro will send out revised material before the call. minutes form July 12 call > - Reviewed Hiro's presenation and XML documents. > > - Jun pointed out that codebase is used incorrectly. It should be > used in the BLAST declaration not in the PosixApplication. > - Also it is not clear what the meaning of pre-script is. > > ACTION: Hiro to talk with Chris Smith and clarify meaning of > pre-script > ACTION: Jun will correct the CDL XML examples written by Hiro. > > - What should be the granular unit of components? > - It may be better to define 'filesystem' or 'database' as > separate components since they may be re-usable in other > contexts. For example, they might be usable also by a 3-tier > application component. > - It was agreed that this kind of refinement is needed. But it is > not a showstopper for delivering the top level CDL for the EMS > sequence scenarios. > > - For the EMS scenarios the following CDL documents are needed: > - Original CDL from the repository; > - CDL modified by JM before submission to Deployment service > (portal) > - CDL after deployment (can be retrieved by JM to refine the JSDL > document) > [The deltas should be fairly small.] > - Some explanation on what the constructs in the CDL document mean > would also be useful since not everyone will have read the CDDLM > documents. > - Also highlighting what information (if any) is expected to taken > from the JSDL document and used in CDL (and vice versa) > - In the simplest case it is 'hostname' and path to the installed > executable. > - Andreas volunteered to review these CDL documents before the EMS > call to make sure they provide the expected information. 3) EMS scenarios (Steven and Andreas, 30 min) Andreas will send out revised scenario document before the call > - EMS team (Steven, Andreas, Donal) to review data staging scenario > (section 5 of https://forge.gridforum.org/sf/go/doc13591?nav=1 ) > Bring to people's attention again at the next EMS call. > (postpone until June 29) > - Add sequence diagrams to the scenarios: (postpone until June 29) > - Andreas will do the "Install application" scenario (3.1) > - Mike will do the "Install application using ACS" scenario (3.3) > - Other volunteers welcome. (Andreas will ask Donal for the EPS > scenario) > - Andreas has started doing the sequence diagrams in RSM > - Darren volunteered to help out > - Review again at the next EMS call (June 29) > - Andreas will merge draft scenarios and sequence diagrams to the > "EMS Architecture Scenarios" document (postpone until June 29) 4) OGSA authorization call-out proposal review (Frank 20 min) > - Frank is now consulting with people in GGF (David Chadwick, Von > Welch) on whether his approach can be defined within the AuthZ > group. If there is no agreement then he will accept the XACML > group's decision. 5) Basic Security Profile Public Comments review (Takuya 20 min) Takuya will send out proposed text change before the call Minutes from June 22nd call > Reviewed public comments and Takuya's proposed replies > 1. Add text explaining that the Secure Channel profile is not > required by all ogsa services. The introduction is probably a > good place for this. > 2. [Basic-Security-Profile] usage. The term is defined in the > document. Takuya to check whether such special terms are used > consistently and that they stand out. Refer to the WSRF BP for a > similar example. > 3. Ciphersuites: Agreed that it important to list acceptable > ciphers. > - As a first step Takuya will list up available ones (from the > WS-I BSP); select the ones that are in common use; and then > select the ones that are considered sufficiently safe. > - Review the list at the next BSP teleconf > 4. Multiple keys in keyinfo field? > - Takuya to talk to Von in order to understand the use case for > multiple keys; and will propose a resolution at the next BSP > teleconf. 6) Wrap up AOB <*NEXT CALL*> July 3 (Mon): Independence day (no call) July 6 (Thu): EMS scenarios (Steven and Andreas) July 10 (Mon): Information model (Ellen and Fred) Roadmap 1.1 (Hiro, ChrisJ, and Jem) Security & BSP Public Comments review (Frank and Takuya) CDDLM & EMS (Jun and Hiro) July 13 (Thu): F2F prep (Tom and Hiro) July 17-20: F2F meeting in Chicago (ANL) Telecon schedule on wiki: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.ogsa-wg/wiki/Telec… <*ACTION ITEMS*> > From June 26 call - Hiro to confirm contact with (ex-)EGA TC > From June 12 call - Jun will correct the CDL XML examples written by Hiro. > From June 8 call - EMS team (Steven, Andreas, Donal) to review data staging scenario (section 5 of https://forge.gridforum.org/sf/go/doc13591?nav=1 ) Bring to people's attention again at the next EMS call. (postpone until June 29) - Add sequence diagrams to the scenarios: (postpone until June 29) - Andreas will do the "Install application" scenario (3.1) - Mike will do the "Install application using ACS" scenario (3.3) - Other volunteers welcome. (Andreas will ask Donal for the EPS scenario) - Andreas has started doing the sequence diagrams in RSM - Darren volunteered to help out - Review again at the next EMS call (June 29) - Andreas will merge draft scenarios and sequence diagrams to the "EMS Architecture Scenarios" document (postpone until June 29) > From May 22 call - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches (postpone until June 19) - Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well (postpone until June 19) > From April 5 F2F meeting - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. Deferred - Frank to write up and send to the list a one page summary of the authorization call-out proposal. (April 24 call, postpone until June 14) - Jay check and find out relatively small funding to Globus to develop document on their security work (April 6 F2F) - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (April 4 F2F) -- Hiro Kishimoto

2 1

OGSA Roadmap Editors call
by Christopher Jordan 28 Jun '06

28 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OGSA Roadmap Document Editors and assorted interested parties, Please join me for a roadmap planning call, Wednesday June 28th at 3pm PDT/6pm EDT/7am (6/29)Tokyo time. We will begin discussing tasks assignments and action items to start reshaping the document, so if you intend to be actively involved in this process, please either join the call or contact me via e-mail in the next day. Your participation is welcomed and encouraged. I have tentative commitments from a few individuals for specific tasks, so I hope to make it a short call, primarily to allow a last chance for new participants and to make sure we're all on the same page as far as the direction we're taking with the document is concerned. From this point on, I hope to make these regular, approximately bi-weekly calls. The call-in information is: Meeting Title: OGSA Roadmap Editing Meeting Date: June 28, 2006 03:00 PM [Pacific Time] Duration: 1 Hour To Join Audio Conference Primary Dial-In: 1 (800) 559-0862 Alternate Dial-In: 1 (630) 424-1461 Passcode: 6102510# Thanks. - ---------------------------------------------------- Chris Jordan HPC Systems Engineer High End Computing Systems Group San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEoepAPCVtcXn6kg8RAnTvAKCffq/ph/L83Dkxlo2kMKmBehaIvQCfR4Yx nYESgGWczSEJEjI0KRGMerM= =0aib -----END PGP SIGNATURE-----

1 0

Teleconference minutes - 26 June 2006
by Andreas Savva 27 Jun '06

27 Jun '06

Attached. Also https://forge.gridforum.org/sf/go/doc13628?nav=1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 26 June 2006 ================================== * Participants Jay Unger (IBM) Jem Treadwell (HP) Andreas Savva (Fujitsu) Tom Maguire (EMC) Fred Maciel (Hitachi) Michael Behrens (R2AD, LLC) Susanne Balle (HP) Minutes: Andreas Savva * June 22 minutes approval postponed - no quorum * Action review - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches (postpone until June 19) - Jay is waiting for material from Miron. * OGSA 1.5 review ** Architecture - Reviewed changes for monolithic issue. - Remaining issues from Geoffrey Fox comments will probably be answered separately. Andreas is talking with Dave S. - Other minor changes to update References per Jem's comment. ** Glossary - Reviewed consumer/producer and agreed to delete the definitions since they do not add anything beyond the normal English meaning of the words. - WS-Notification status is still proposed; leave the comment in until the final draft is put out - WSRF status needs update ** Next step - Andreas will confirm with Dave S about the rest of the comments and then send out final drafts for Architecture and Glossary. * Other documents - WSRF Basic Profile expected to be published soon (finished GFSG review) - Basic Security Profiles finished public comment and now in Author review. * New gridforge - The new gridforge is still not allowing users to put in comments to documents under review. - 'Copying' a document in the old gridforge created a hard link; in the new one it is a separate copy. Andreas had to delete all the working drafts that were linked under the Root folder for convenience. He will put together a summary wiki page to current drafts. - Jem is thinking of keeping track of a document state on the wiki (e.g., draft, public comment, etc). This relates a bit to the Roadmap but is smaller scale; just for the OGSA-WG products. - WG front page needs customization, e.g., move links under "Group Information." - Andreas has linked the public calendar into the OGSA forge site and will be announcing it on the list. * GGF18 planning Based on the current work of the group the main topics should be Information Modeling and EMS. Proposal worked on the call is for 4 sessions and an option for a one day F2F, if necessary. - Information modeling: Two back-to-back sessions (90 minutes each) - Info-Model has an overlap with a number of other groups but it is probably better to keep the discussion within one group (OGSA) for now. - The first session on basic information modeling and the next on its relation/application in other groups (BES/JSDL/RSS). - EMS (Scenarios, CDL, etc): One session (perhaps 45 minutes) - OGSA and EGA reference architecture: One session - With the new OGF it may be worth to start discussing how the EGA work fits in. - Need to confirm contact with the (ex-)EGA TC - (Paul Strong was the previous contact but it looks like he is not involved anymore) - Other topics depending on the July F2F results so a 'placeholder' session might be needed if we have to submit requests by July 7. - Option for a back-to-back F2F. - Not clear if it will be necessary - A couple of possibilities for facilities are IBM (Jay) and Northorp Grumman (Pete Ziu) but confirmation is needed. ACTION: Hiro to confirm contact with (ex-)EGA TC

2 1

Public OGSA calendar
by Andreas Savva 27 Jun '06

27 Jun '06

This is to let you know that I have set up an events calendar for OGSA-WG. It is available through the OGSA-WG Gridforge page as a linked application. Go to https://forge.gridforum.org/projects/ogsa-wg/ and look for the 'Calendar' button. Or choose one of the urls below. Teleconference agendas, interim meeting schedule and other events will be posted to this calendar. More tentative planning/schedule information may initially be on the wiki instead. https://forge.gridforum.org/sf/wiki/do/viewPage/projects.ogsa-wg/wiki/Telec… In addition to the Agendas that Hiro is sending out before the teleconferences we will also start sending *calendar invitations*. If you are a regular participant and you have a client that can respond to such invitations please feel free to do so. If not, the invitations may not display properly, sorry. Calendar links: [View it on Gridforge] https://forge.gridforum.org/sf/linkedapplication/do/viewLinkedApplication/p… or http://tinyurl.com/krhe3 [Subscribe using RSS] http://www.google.com/calendar/feeds/ogsa.wg@gmail.com/public/basic [Subscribe using ICAL] http://www.google.com/calendar/ical/ogsa.wg@gmail.com/public/basic Thanks to Google Calendar. -- Andreas Savva Fujitsu Laboratories Ltd

1 0

Proposed agenda for June 26th call
by Hiro Kishimoto 26 Jun '06

26 Jun '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on June 26th Monday from 5pm to 7pm (CDT). I will attend off-site seminar on Monday and Tuesday and cannot make the call. Andreas and Tom will chair this call. The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0626 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (June 22) - https://forge.gridforum.org/sf/go/doc13624?nav=1 Action Items status review (see the bottom of this email) Agenda bashing 2) Architecture & Glossary 1.5 final text review (Andreas & Jem, 60 min) Andreas and Jem will send out final draft before the call > - Andreas categorized OGSA 1.5 issues and sent the list to > Dave Snelling. > - Review at next "OGSA 1.5" call. 3) GGF18 session plan (Tom and Andreas, 30 min) Joel asks us to make session request by July 7th. 4) Wrap up (10 min) AOB <*NEXT CALL*> June 29 (Thu): EMS scenarios (Steven and Andreas) CDDLM & EMS (Jun and Hiro) Security & BSP Public Comments review (Frank and Takuya) GGF18 session plan (Tom and Andreas) July 3 (Mon): Independence day (no call) July 6 (Thu): EMS scenarios (Steven and Andreas) July 10 (Mon): Information model (Ellen and Fred) Roadmap 1.1 (Hiro, ChrisJ, and Jem) Security & BSP Public Comments review (Frank and Takuya) CDDLM & EMS (Jun and Hiro) July 13 (Thu): F2F prep (Tom and Hiro) July 17-20: F2F meeting in Chicago (ANL) Telecon schedule on wiki: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.ogsa-wg/wiki/Telec… <*ACTION ITEMS*> > From June 12 call - Jun will correct the CDL XML examples written by Hiro. > From June 8 call - EMS team (Steven, Andreas, Donal) to review data staging scenario (section 5 of https://forge.gridforum.org/sf/go/doc13591?nav=1 ) Bring to people's attention again at the next EMS call. (postpone until June 29) - Add sequence diagrams to the scenarios: (postpone until June 29) - Andreas will do the "Install application" scenario (3.1) - Mike will do the "Install application using ACS" scenario (3.3) - Other volunteers welcome. (Andreas will ask Donal for the EPS scenario) - Andreas has started doing the sequence diagrams in RSM - Darren volunteered to help out - Review again at the next EMS call (June 29) - Andreas will merge draft scenarios and sequence diagrams to the "EMS Architecture Scenarios" document (postpone until June 29) > From May 22 call - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches (postpone until June 19) - Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well (postpone until June 19) > From April 5 F2F meeting - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. Deferred - Frank to write up and send to the list a one page summary of the authorization call-out proposal. (April 24 call, postpone until June 14) - Jay check and find out relatively small funding to Globus to develop document on their security work (April 6 F2F) - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (April 4 F2F) -- Hiro Kishimoto

3 2

Proposed agenda for June 22nd call
by Hiro Kishimoto 22 Jun '06

22 Jun '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on June 22nd. Thursday from 8:30am - 10:30am (CDT). Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0622 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (June 12 & 15) https://forge.gridforum.org/sf/go/doc13593?nav=1 https://forge.gridforum.org/sf/go/doc13618?nav=1 Action Items status review (see the bottom of this email) Agenda bashing 2) Information model (Jay, Andreas and Fred, 30 min) > - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) > to get feedback on pros / cons of the two rendering approaches > (postpone until June 19); and > - Darren/Andreas will take the Modeling position paper and discuss > it within the JSDL-WG as well (postpone until June 19) > > - Jay has talked with Miron. There is no written material ready > yet. > - Andreas has raised the issue on the JSDL call. Overall it is not > clear to people if this rendering choice boils down to anything > more than a style choice. > - People interested in this topic were asked to come to the OGSA > call. You can download current material from here; - Information Modeling in OGSA - Position Paper https://forge.gridforum.org/sf/go/doc13073?nav=1 - BES Information Model https://forge.gridforum.org/sf/go/doc13074?nav=1 - Guidelines on information modeling for OGSA https://forge.gridforum.org/sf/go/doc12798?nav=1 3) Roadmap 1.1 (ChrisJ, Hiro, and Jem, 30 min) Open issues and plan for roadmap 1.1 4) OGSA authorization call-out proposal review (Frank 20 min) > - Frank is now consulting with people in GGF (David Chadwick, Von > Welch) on whether his approach can be defined within the AuthZ > group. If there is no agreement then he will accept the XACML > group's decision. 5) BSP Public Comments review (Takuya 20 min) Public Comments period for BSP ends June 20th. Takuya will report out comments posted and how to handle them. 6) Wrap up AOB <*NEXT CALL*> June 26 (Mon): Architecture & Glossary 1.5 (Andreas and Jem) GGF18 session plan (Tom and Andreas) June 29 (Thu): EMS scenarios (Steven and Andreas) CDDLM & EMS (Jun and Hiro) Security & BSP Public Comments review (Frank and Takuya) GGF18 session plan (Tom and Andreas) July 3 (Mon): Independence day (no call) July 6 (Thu): EMS scenarios (Steven and Andreas) July 10 (Mon): Information model (Ellen and Fred) Roadmap 1.1 (Hiro, ChrisJ, and Jem) Security & BSP Public Comments review (Frank and Takuya) CDDLM & EMS (Jun and Hiro) July 13 (Thu): F2F prep (Tom and Hiro) July 17-20: F2F meeting in Chicago (ANL) Telecon schedule on wiki: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.ogsa-wg/wiki/Telec… <*ACTION ITEMS*> > From June 15 call - Andreas will categorize OGSA 1.5 issues and send the list to Dave Snelling. - Andreas and Hiro to talk offline about how to start sending ical invitations. > From June 12 call - Jun will correct the CDL XML examples written by Hiro. > From June 8 call - EMS team (Steven, Andreas, Donal) to review data staging scenario (section 5 of https://forge.gridforum.org/sf/go/doc13591?nav=1 ) (postpone until June 22) - Add sequence diagrams to the scenarios: (postpone until June 22) - Andreas will do the "Install application" scenario (3.1) - Mike will do the "Install application using ACS" scenario (3.3) - Other volunteers welcome. (Andreas will ask Donal for the EPS scenario) - Andreas will merge draft scenarios and sequence diagrams to the "EMS Architecture Scenarios" document (postpone until June 22) > From May 22 call - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches (postpone until June 19) - Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well (postpone until June 19) > From April 5 F2F meeting - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. Deferred - Frank to write up and send to the list a one page summary of the authorization call-out proposal. (April 24 call, postpone until June 14) - Jay check and find out relatively small funding to Globus to develop document on their security work (April 6 F2F) - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (April 4 F2F) -- Hiro Kishimoto

2 1

Telecon schedule on the wiki
by Hiro Kishimoto 19 Jun '06

19 Jun '06

Hi all, OGSA weekly telecon schedule up until July F2F meeting is now on the wiki page. https://forge.gridforum.org/sf/wiki/do/viewPage/projects.ogsa-wg/wiki/Telec… If you have any comments or questions, please let me know. Thanks, -- Hiro Kishimoto

1 0

No call on June 19th
by Hiro Kishimoto 18 Jun '06

18 Jun '06

Hi all, Since June 19th does not work for many folks, "Info Model discussion" should be moved to Thursday June 22. Thus we have no call on June 19th and have full agenda on 22nd. Minutes from June 15: > - Because it is not clear who can attend on Monday the consensus > was to move the Info Model discussion from Monday to another > day, e.g., Thursday. > > ACTION: Hiro to look into re-scheduling the Info Model rendering > discussion to another day (Thursday?) <*NEXT CALL*> June 22 (Thu): Information model (Ellen and Fred) EMS scenarios (Steven and Andreas) Roadmap 1.1 (Hiro, ChrisJ, and Jem) Security & BSP Public Comments review (Frank and Takuya) June 26 (Mon): Architecture & Glossary 1.5 (Andreas and Jem) CDDLM & EMS (Jun and Hiro) June 29 (Thu): Security & BSP Public Comments review (Frank and Takuya) July 3 (Mon): Independence day (no call) July 6 (Thu): EMS scenarios (Steven and Andreas) Thanks, -- Hiro Kishimoto

1 0

Teleconference minutes - 15 June 2006
by Andreas Savva 16 Jun '06

16 Jun '06

Attached. https://forge.gridforum.org/sf/go/doc13618?nav=1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 15 June 2006 ================================== * Participants Hiro Kishimoto (Fujitsu) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Jem Treadwell (HP) Jay Unger (IBM) Apologies: Tom Maguire, Michael Behrens, Frank Siebenlist Minutes: Andreas Savva * Summary of Actions ACTION: Hiro to look into re-scheduling the Info Model rendering discussion to another day (Thursday?) ACTION: Andreas will categorize OGSA 1.5 issues and send the list to Dave Snelling. ACTION: Andreas and Hiro to talk offline about how to start sending ical invitations. * Minutes June 12 approval postponed (no quorum) * Security discussion postponed * Actions review - Hiro will upload updated F2F agenda (mainly updates to the attendees list) - Done - Hiro to talk with Chris Smith and clarify meaning of pre-script - Sent email, waiting. - Hiro to send Chris J the names of the people that provided Roadmap sections in the past. - Done - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches (postpone until June 19); and - Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well (postpone until June 19) - Jay has talked with Miron. There is no written material ready yet. - Andreas has raised the issue on the JSDL call. Overall it is not clear to people if this rendering choice boils down to anything more than a style choice. - People interested in this topic were asked to come to the OGSA call. - Because it is not clear who can attend on Monday the consensus was to move the Info Model discussion from Monday to another day, e.g., Thursday. ACTION: Hiro to look into re-scheduling the Info Model rendering discussion to another day (Thursday?) * OGSA 1.5 Review ** OGSA 1.5: Architecture review - Andreas has uploaded Geoffrey Fox's presenation. He is reviewing it and will identify which issues relate to the document (there is at least one) and which do not. Items that do not relate to the document will be answered separately, perhaps as part of a Q&A on the WG's wiki. - Jay is also willing to provide answers to some of the issues. ACTION: Andreas will categorize OGSA 1.5 issues and send the list to Dave Snelling. ** OGSA 1.5: Glossary review - Reviewed Jem's proposed updates. (Details on Jem's updated draft.) - Agreed that the definition for 'provisioning/deployment' should be left for later; depending on whether there is sufficient consensus to change it. In any case the usage in the Arch document has not changed. ** Next steps - Agreed to do a final text review 2 weeks from now. It is ok to do the reviews of the two documents separately if necessary. * Other business: OGSA Calendar - Andreas has set up and been updating an online google calendar. It has been visible to a small number of people. The plan is to make it publicly available so that people can refer to an up to date view of the teleconference and meeting schedule. - Jay proposed starting to send ical invitations to the list. Since the calendar account is on the list the online calendar view will be automatically updated---no need to manually enter events. - For example, Hiro would send an ical invitation instead of (or in addition to) the normal agenda. - The other advantage is that Hiro could get information on who intends to attend. This might be useful for F2F planning, e.g., identify who plans to join which session by phone. - Agreed to schedule a short discussion (update) again on the Monday teleconference ACTION: Andreas and Hiro to talk offline about how to start sending ical invitations.

1 0

Proposed agenda for June 15th call
by Hiro Kishimoto 15 Jun '06

15 Jun '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on June 15th Thursday from 8:30am - 10:30am (CDT). Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0615 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (June 12th) https://forge.gridforum.org/sf/go/doc13593?nav=1 July F2F meeting update (if any) Action Items status review (see the bottom of this email) Agenda bashing 2) OGSA authorization call-out proposal review (Frank 20 min) > - Frank is now consulting with people in GGF (David Chadwick, Von > Welch) on whether his approach can be defined within the AuthZ > group. If there is no agreement then he will accept the XACML > group's decision. > > - Review status again on the June 15 teleconference. > 3) Basic Security Profile public comment review (Takuya 20 min) Public comment periods will end June 20th. Takuya will lead the evaluation and possible response to already posted comments: https://forge.gridforum.org/sf/discussion/do/listTopics/projects.ggf-editor… https://forge.gridforum.org/sf/discussion/do/listTopics/projects.ggf-editor… 4) Architecture & Glossary 1.5 comment review (Andreas and Jem 40 min) > - Discussed what to do if no more comments are received. Agreed that > since this is a minor revision a second round of public comment is > not necessary. The group will make whatever minor changes are > needed and submit the document to the GGF Editor. > > - The glossary has more comments but it expected that if no other > comments are received the documents can be revised and > re-submitted in June. 5) Wrap up (10 min) AOB <*NEXT CALL*> June 19 (Mon): Information model (Ellen and Fred) June 22 (Thu): EMS scenarios (Steven and Andreas) Roadmap 1.1 (Hiro, ChrisJ, and Jem) June 26 (Mon): Security & BSP Public Comments review (Frank and Takuya) CDDLM & EMS (Jun and Hiro) June 29 (Thu): Architecture & Glossary 1.5 (Andreas and Jem) July 3 (Mon): Independence day (no call) July 6 (Thu): EMS scenarios (Steven and Andreas) <*ACTION ITEMS*> > From June 12 call - Hiro will upload updated F2F agenda (mainly updates to the attendees list) - Hiro to talk with Chris Smith and clarify meaning of pre-script - Jun will correct the CDL XML examples written by Hiro. - Hiro to send Chris J the names of the people that provided Roadmap sections in the past. > From June 8 call - EMS team (Steven, Andreas, Donal) to review data staging scenario (section 5 of https://forge.gridforum.org/sf/go/doc13591?nav=1 ) (postpone until June 22) - Add sequence diagrams to the scenarios: (postpone until June 22) - Andreas will do the "Install application" scenario (3.1) - Mike will do the "Install application using ACS" scenario (3.3) - Other volunteers welcome. (Andreas will ask Donal for the EPS scenario) - Andreas will merge draft scenarios and sequence diagrams to the "EMS Architecture Scenarios" document (postpone until June 22) > From May 22 call - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches (postpone until June 19) - Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well (postpone until June 19) > From April 5 F2F meeting - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. Deferred - Frank to write up and send to the list a one page summary of the authorization call-out proposal. (April 24 call, postpone until June 14) - Jay check and find out relatively small funding to Globus to develop document on their security work (April 6 F2F) - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (April 4 F2F) -- Hiro Kishimoto

2 1

Regrets
by Maguire_Tom＠emc.com 15 Jun '06

15 Jun '06

Sorry, unexpected eval that I have been pulled into. Tom +1 (845) 729-4806 Blackberry Connect for Palm

1 0

Interim July F2F meeting agenda
by Hiro Kishimoto 15 Jun '06

15 Jun '06

Hi all, The latest agenda for Interim July F2F meeting is now on GridForge. https://forge.gridforum.org/sf/go/doc13607?nav=1 Thanks, -- Hiro Kishimoto

1 0

Glossary: Provisioning/deployment definitions
by Treadwell, Jem 14 Jun '06

14 Jun '06

Hi, On Thursday's call we'll be looking at the two open trackers for the Glossary 1.5. Tracker 1775 says: Reconsider the definition of provisioning (and maybe deployment), per the minutes of the 3/13/2006 OGSA telecon, and depending on the eventual definition agreed by BES & CDDLM. Defer until the next OGSA version if it is premature at v1.5. We need to make a decision on Thursday as to whether to change these definitions for this version. I haven't heard of any agreement on this in the other groups, but if (despite the attraction of a Glossary discussion) you're not going to be on Thursday's call and you have input about this, please let me know. We'll also be reviewing the remaining items in tracker 1770. Thanks! - Jem

1 0

OGSA Roadmap editors meeting notes
by Christopher Jordan 14 Jun '06

14 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Attendees: Chris Jordan, Patricia Kovatch (SDSC) Dona Dickinson (NGC) Mike Behrens (R2AD) The meeting consisted primarily of an overview of proposed organizational/preparational tasks, listed below with responsible parties Getting Contact Information for all groups (Chris will get from Hiro, Dona will maintain future list) Getting new document list for inclusion in next Roadmap document (Chris will discuss with Hiro, Jem, and OGSA-WG) Chris feels that section 1 needs to be rewritten to provide a more general motivation, as the current version focuses on follow-on activities to the release of the OGSA 1.0 Architecture document. One proposed addition/replacement for this section is a more detailed history of the GGF/OGSA efforts, and their relationship to other ongoing Grid Services standards work. (Chris has agreed to begin work on this) Chris: The areas of section 2 regarding "OGSA process and compliance", and the ability of implementations to claim various levels of OGSA-conformance seems to need re-examination or clarification - It is not clear to the editing team how a "compliance test" for some of the involved standards documents would be implemented, and the number of levels of conformance seems overly complex. It is also not clear how the various levels relate to the ability of implementations to interoperate. Also need clarification on OGSA process discussion. (It was suggested that the process and compliance material might be best placed in a related but separate document. This topic has been deferred for later discussion, ideally with Hiro, Jem, and possibly the entire group) All participants agreed that the document should include at least a more detailed summary of lower-level standards which OGSA and related documents build upon or assume some implementation of (I.E. XML, Schemas, WSDL, WSRF, etc), without including detailed tracking information for each of these standards. (Mike Behrens will work on gathering status and relationship information for Web services standards. The OGSA community is actively encouraged to submit individual visions of the software/ standards stack) Mike Behrens suggested that it would be helpful to include a new section on the future vision of OGSA and how that fits within the overall grid computing landscape. What documents have been proposed, and what are needed? The above topic relates to Gap Analysis, a topic which was deferred for later discussion, once we have a better sense of how the new version of the document will take shape. Open Items: The overall vision for the roadmap, and the new documents to be included, probably need to be discussed in an official forum - Chris will propose to Hiro either a session at the OGSA F2F in July, or a discussion on one of the weekly conference calls, to try and get some feedback from the group on both topics. We still need to reformat the data in the spreadsheet into a relational database or other, more manageable form - it was generally agreed that the current status spreadsheet is frightening, at best. We may need a shared web-space backended by a relational database to manage both the project and the technical data involved. it is possible that R2AD may be able to host this space, if GridForge is determined to be inadequate to the needs of the project. The final item is the question of whether a call should be held this wednesday - Chris will be on travel next week, so will be available this week, then unavailable until the last week of june. If Hiro and Jem are available to discuss some of the open items and topics listed above, I believe a call could be useful. Otherwise, I propose we stick to e-mail and schedule the next call for Wednesday, June 28th. Thanks to all the participants. Comments and questions are welcome. - ---------------------------------------------------- Chris Jordan HPC Systems Engineer High End Computing Systems Group San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEjaYBPCVtcXn6kg8RAgExAKDipRS05Yap0XKAjqi6r3iHzG5uKACeMu4t wdbqWdg0Wi490ecb9xtlygU= =sUgz -----END PGP SIGNATURE-----

1 1

GGF OGSA HPC Profile WG created
by Marty Humphrey 13 Jun '06

13 Jun '06

Folks, Just a quick announcement that the OGSA HPC Profile WG has been formed in the GGF. If you are interested in subscribing to the email list, see the forwarded email, below, for instructions). Recently, we have had discussions on the BES and JSDL mailing lists that follow-up on our OGSA HPC Profile BOF at GGF17 (see http://www.ggf.org/mail_archive/ogsa-bes-wg/2006/06/maillist.html and http://www.ggf.org/mail_archive/jsdl-wg/2006/06/maillist.html) We will start to continue these discussions on this new OGSA HPC mailing list. In addition, the gridforge project web page has been created: https://forge.gridforum.org/sf/projects/ogsa-hpcp-wg We will be uploading the current docs in the next couple of days. It's taking a little bit of time to convert the current docs (particularly the use-case doc) into the appropriate GGF format. Note that Gridforge recently changed -- Users from the previous version will need to click the 'Forgot Password' link to set a new password (the authentication scheme changed in the new version). -- Marty -----Original Message----- From: Joel Replogle [mailto:replogle@ggf.org] Sent: Wednesday, June 07, 2006 4:36 PM To: Marty Humphrey Cc: theimer(a)microsoft.com Subject: osga-hpcp-wg email list Marty/Marvin - I just received word that the email list has been set up. Sorry for the delay. You can invite whomever you'd like to subscribe themselves to the list by sending an email message to "majordomo(a)ggf.org" with the following line in the body of the message (subject is ignored): subscribe ogsa-hpcp-wg Thanks, Joel ------------------------------------------------------------------------ ----------- Joel Replogle - Manager of Standards, Global Grid Forum replogle(a)ggf.org http://www.ggf.org <http://www.ggf.org/>

1 0

Teleconference minutes - 12 July 2006
by Andreas Savva 13 Jun '06

13 Jun '06

Gridforge url: https://forge.gridforum.org/sf/go/doc13593?nav=1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 12 June 2006 ================================== * Participants Jem Treadwell (HP) Jun Tatemura (NEC) Andreas Savva (Fujitsu) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Chris Jordan (SDSC) Mike Behrens (R2AD, LLC) Apologies: Tom Maguire Minutes: Andreas Savva * Summary of New Actions ACTION: Hiro will upload updated F2F agenda (mainly updates to the attendees list) ACTION: Hiro to talk with Chris Smith and clarify meaning of pre-script ACTION: Jun will correct the CDL XML examples written by Hiro. ACTION: Hiro to send Chris J the names of the people that provided Roadmap sections in the past. * June 8 minutes approved with no changes * July F2F updates ACTION: Hiro will upload updated F2F agenda (mainly updates to the attendees list) * Action item review - EMS team to review data staging scenario (section 5 of https://forge.gridforum.org/sf/go/doc13591?nav=1) ... - Add sequence diagrams to the scenarios ... - Andreas will merge draft scenarios and sequence diagrams ... Above three actions to be re-reviewed on the next EMS call. - Jay will contact Platform (Chris Smith) and Condor ... - Darren/Andreas will take the Modeling position ... Above two actions to be re-reviewed on the next Information Modeling call * CDDLM & EMS - Reviewed Hiro's presenation and XML documents. - Jun pointed out that codebase is used incorrectly. It should be used in the BLAST declaration not in the PosixApplication. - Also it is not clear what the meaning of pre-script is. ACTION: Hiro to talk with Chris Smith and clarify meaning of pre-script ACTION: Jun will correct the CDL XML examples written by Hiro. - What should be the granular unit of components? - It may be better to define 'filesystem' or 'database' as separate components since they may be re-usable in other contexts. For example, they might be usable also by a 3-tier application component. - It was agreed that this kind of refinement is needed. But it is not a showstopper for delivering the top level CDL for the EMS sequence scenarios. - For the EMS scenarios the following CDL documents are needed: - Original CDL from the repository; - CDL modified by JM before submission to Deployment service (portal) - CDL after deployment (can be retrieved by JM to refine the JSDL document) [The deltas should be fairly small.] - Some explanation on what the constructs in the CDL document mean would also be useful since not everyone will have read the CDDLM documents. - Also highlighting what information (if any) is expected to taken from the JSDL document and used in CDL (and vice versa) - In the simplest case it is 'hostname' and path to the installed executable. - Andreas volunteered to review these CDL documents before the EMS call to make sure they provide the expected information. - What is filesystem 'normal' and 'temporary'? - These are JSDL terms defining filesystem persistency. They only address the simplest cases. More information (e.g., performance characteristics) may be added in but such information is not standardized by JSDL---though there may be examples in the spec. - Chris J mentioned that there has been some work on a Data Scenario (for GFS) that looks at how to represent a global filesystem (available locally or as a separate resource). It will eventually be included in the Scenarios document that Dave B mentioned on the last call. * New Gridforge issues - The new WG page is different from the old one. Many links that Jem had added in the past are missing. - Andreas talked to Joel and was told that the new page is autogenerated from the live charter. - Jem will look into the possibility of customizing a part of the front page. In any case a WG wiki is available so a lot of the information should be put there. - There is a problem with the trackers. Artifacts with multiple files attached were not migrated correctly. (Only one file per artifact made it through; the rest came as 8 bytes.) - Andreas has submitted the issue on the gridforge feedback (wiki) page. The gridforge admins (Joel and Andre) are looking into it. Feedback wiki url: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.ggf-info/wiki/Grid… * Roadmap update - Chris J has had a Roadmap Editor call and has sent the minutes out on the list. - A teleconference with Jem and Hiro and the new team should be arranged. ACTION: Hiro to send Chris J the names of the people that provided Roadmap sections in the past.

1 0

Proposed agenda for June 12th call
by Hiro Kishimoto 12 Jun '06

12 Jun '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on June 12th Monday from 5pm to 7pm (CDT). The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0612 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (June 8th) https://forge.gridforum.org/sf/go/doc13592?nav=1 July F2F update (if any) Action Items status review (see the bottom of this email) Agenda bashing 2) CDDLM & EMS (Jun and Hiro, 40 min) Review CDDLM-WG's feedback on Andreas' CDDLM scenario. Jun and Hiro to provide a CDL document example. > Last week on the ogsa call we reviewed the EMS scenario (posix > application) that includes a simple interaction between JSDL and CDL > documents. The major missing piece at the moment is the CDL document, > as an actual XML document. Can I ask you to write up such a document? > I am only interested in the 'top level' (sorry for using perhaps the > wrong terminology) CDL BLAST document. I think it only has to > highlight > 1) hostname as lazy (so that we can show how the JM may choose to > provide that value) > 2) BLAST binary deployment > > Last time we talked about it (April F2F) I think this discussion got > somewhat sidetracked by, among other things, the observation that a > general posix application component also had to be defined to support > the 'top level' CDL BLAST document. For this EMS scenario I think it > is *not* necessary to have such a general component defined as long as > there is sufficient explanation accompanying the BLAST CDL document on > what underlying definitions are assumed. 3) Wrap up (10 min) AOB <*NEXT CALL*> June 15 (Thu): Security & BSP Public Comments review (Frank and Takuya) Architecture & Glossary 1.5 (Andreas and Jem) June 19 (Mon): Information model (Ellen and Fred) Roadmap 1.1 (Hiro, ChrisJ, and Jem) June 22 (Thu): EMS scenarios (Steven and Andreas) June 26 (Mon): Security & BSP Public Comments review (Frank and Takuya) CDDLM & EMS (Jun and Hiro) <*ACTION ITEMS*> From June 8 call - EMS team to review data staging scenario (section 5 of https://forge.gridforum.org/sf/go/doc13591?nav=1 ) - Add sequence diagrams to the scenarios: - Andreas will do the "Install application" scenario (3.1) - Mike will do the "Install application using ACS" scenario (3.3) - Other volunteers welcome. (Andreas will ask Donal for the EPS scenario) - Andreas will merge draft scenarios and sequence diagrams to the "EMS Architecture Scenarios" document >From May 22 call - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches - Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well >From April 5 F2F meeting - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. Deferred - Frank to write up and send to the list a one page summary of the authorization call-out proposal. (April 24 call, postpone until June 14) - Jay check and find out relatively small funding to Globus to develop document on their security work (April 6 F2F) - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (April 4 F2F) -- Hiro Kishimoto

2 3

July F2F agenda v3
by Andreas Savva 12 Jun '06

12 Jun '06

I am attaching the revised agenda for the July F2F as decided on the call today. We re-worked the meeting-at-a-glance table on page 4 to fit in a couple of new requests and also make it easy for people to dial in from Europe. Please let Hiro and I know if there are any other requests. Andreas

2 1

Regrets today. Continuation of personal appointment from last week.
by Maguire_Tom＠emc.com 12 Jun '06

12 Jun '06

0 *H÷ 010 +0 *H÷ $Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C68DFC.3851D580" X-MS-TNEF-Correlator: 20924CBF1D8EC601 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C68DFC.3851D580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tom _______________________________________________ Tom Maguire Senior Technologist, Office of CTO EMC2 maguire_tom(a)emc.com +1(845) 729-4806 ------=_NextPart_000_0000_01C68DFC.3851D580 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IgQMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgDIDwAAHwAAAAsAHw4BABIAAgH4DwEAAAAQAAAAGTFs0enA QU+TG+xdGMv50gIB+g8BAAAAEAAAAEcAeBfHkKxKr+8LploFF7ADAP4PBQAAAAMADTT9PwUAAwAP NP0/BQACARQ0AQAAABAAAABUlKHAKX8QG6WHCAArKiUXHgD6PwEAAAANAAAATWFndWlyZSwgVG9t AAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwARgAggBgAAAAAAwAAAAAAAAEYA AAAAAYUAAAAAAABAABOACCAGAAAAAADAAAAAAAAARgAAAABghQAAAAjW6CkAAAALABCACCAGAAAA AADAAAAAAAAARgAAAAADhQAAAAAAAAsABoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAD gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAGqACCAGAAAAAADAAAAAAAAARgAAAAAYhQAA AAAAAAsAcIAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAAAgEJEAEAAACpDAAApQwAAOYcAABM WkZ1w3aD/gMACgByY3BnMTI1GjIMYGMAUAEEc3Rz4mgFcGJjaA71CQAPh2ZoDeAPlmJpAUMLYG6R DhAwMzMRpmZlEiI/AfcCpANjAgAPgArAc2VCdALRcHJxMgAAKskKoW5vFOAgMAHQAdDCNhIwMDUw NBaxAdD5FqA0fQdtAoMAUAPUFI/9FZtiFnEW4BZCG4QXYAcT+QKDMzYY3xnvGvcWpBti2RdhYWgD cQKDMhbgFB4oMjM4HhQgB20gQ35FINUYwSF9FtAijyOVec5yINUSUBQtMTYYwSXv9QOCRwnRayDV JbEoDg5QWykvA3NUCHAg1TUrXzeGNyyPI5QoSGViCXD8dykg1RzxLs4ifzDWBxDfAaAN4DG2L8Eo DTgc8TOf9QOCQgdAdA3gINUzYSgOFyfRNz8xA1YIkHRuYf0HgWUxtRbAHQ4iWAcTI+feNRjPJZg+ 5SdGNSfRHSz3KOg+5CqJNSWxQr4sdj7kfS33NS6RQr0vtz7kMUw17xz/M0hJtTT7NS/BQr029/s+ 5DiKNTNhQr46hkm1PB7/FoA9PyJZIIMj5haAP98lmf9V5SdFFoFQ/yj4VeQqiBtB/1mvLGhV5C32 FoBIDy+pVeT/MUsWgEsPM0lg9TT6FoBOD/826VXkOIkWgFDvOmlg9VMPXDA5Vu9soGB9VB2gaVcx sQKRCOY7CW8wbu9l/0fhcBpH4nD/cghwBEficI8/dF90HXOfcc9wHxLwMjj/eep7AXq/e8lwBHvy el9+L+997X1ve59/ZDkOUIK0hBFPfDOEEAKCDxB5bAeQaNUJ4HQAAHEDIWwRgQUQwwFAA/BkY3Rs CrEAYB5zCrCHUB2gh5JudW1BAgBhYXV0bwBgZIxqdQ8QBRBnaHSGsZcKAYaACgFpAZBwMAOy/yEg hnAR9hKoCNAJwIcQiyMcbnCLeY0UAzBzbmV+eB3wB7AFsADAAnMVoGMucxIgAzCJEGSKcGl25xYQ DwAd0G1pEMCQAAnwnCBEARCIwDigIFAKwMZhCcCKkGggRgIhjzTdDyAxAFAPIANgdwswiWCJAYBz V4cQdGhCElB3iWAKsJAAbBIgM2CUpHJflRgQAJSGAYCWh2KWh3LjlIEE8GVsbIcBlFCT8f8BQA8g kFAAIDiRkwExcJWgf5oGCVCaJAyxmjOHgJokZK5nmwacgJwGaJoVdgMw/4ZPh1+Ib4l/ioeiMRHz iwX/EuKLAYx8o8elRI5FkzCQfNeO1FXBAmBljzc1j9qRkPcI0CEQjkFin9AJgAIgj7KvhYEdwJ9A KPAyhAAzOuB4SHlwBJCKISrDj3M2/6lPqxKqn6unknCYwJOQCYD/rD8voI/aGLMMAa5fkJoPAD2s UXMCID8RDwAFoG1w2xXyqz5FAMADEFOFki+g924TFaALYHQJ8A8ghZOeoMxzZA8QB3BheKkgYkDb uWEQEWsJgAEBMI9DbwBidgJRIHtVrKAV4HdfGGG7BKuBu4K8ozgugDF/JbCrcr2wP8AsYatybKA3 3w5AAFCrciRwVBAyYkC/Q7ksYDc5a5CrcgHAODNQ/57RwLKsAIQAwISEEGVAvuA/vdTCYb2AvyQO IGVAMzH/ElC95DpwOUDEFUJwhABK8XnE9Dk4R/DAhDNBfIAzt8KVwGAW0DfFlcBhNsbQ/73Ux5DG 0b3FwkEWcMQVyGD+Nr7wxZXIYcQAwISr0JUR5jbLlqvwNDm/JGygFqL7v9QiUDc1wC6BvpMnwMEg /83GLoC+Qb3EvuAo4VmB0DTfyqAWsMCEFqDAcDnOhRzgf77gEkC/1M5BLoCLAdGzOP028DZCcdP0 q/A/wDNgv0TpFoAyOcKUNNBxLoDWF//Ksc6UMiDQAM52OUBH8DNQ/78lwQFoIr9DzQDKkMYQ2eb/ xXAMAatyzbEugNYFFsDGwf/NBUfwQmGr8Ntk0ADHkMBg/9tk0WDG0Mhw22TEwBJAL7H/3zRFQAHA zpTGAMqgIlDAhP+rteFlxMBK8OIV1nDV8Csx/+L01QCpIMKU1HDY4QHA5GX/1dHghcxAVBCr8NVU 3sHGEP/ExdCAwZAkcL50wZBfEeCF/85Q1gAvoME1aCEsYOjVKPD/hAHmlcEgJ8DEBcBhwZDOUP+9 NMJh1gDBNMTAx5AWoMKU/zbwSvDsd9Rwx8DTBdRBq/D/FjDvpcBgEkDtVavwwGBH8f/CAxaw35G9 xPIxwZDFhc0A/8PwL7DVVKvxEkDFcMH00ID/FqHClMhRzlASQcK0EjDOUP8o8cK0NuDisciV95He wdVU/6OixgG9xeuRxgDVRRIg3fH/FnDGVWVATfDWAM6UlREugP8SMPjF/GIrMMNVEiDSMCjw//wF kzAyIPCx/OV8gKvQ0wX/kzAc4PMh/aZH8ONB/0Zrcf+r4cNmxtH4tsvw6UE1wcN0/77hlRIERctg yQHDZdLxq/D/xlU1sSJQzoUOIS+g1nDDVv/j8Urww1bZkdUAvcV8gBbQ/8V3CkHZggnmLoDM8AaW wQD/xKD7Ju3xFrDjhfPB1RFFQf8NNO3BvZENJT/AP8D0xQ/h/91Q0TEPlsEAa3IPpYQQB+H/DSXh IMSRDRbIYAcxESbWAP//EcZVFuDFcSExveTt8dCA/xYHUNDKoBU227B8gNeFviL/2OHFlcAx7cEW BstR7pEaKP/ewb3V0jDZoRYGyGBoMPEF/6kga4DRUcTWviHGAB1WIlD/1HDEx7/A0hH4xb8AEoHw Rf+pIPsAvYAE5kfw8ZEaBkrw/8fAhBDGVUrwFRGTMcT08aH/D+HE5ctgwzHFl6vw1HYsUf/t4YQR JzTUcCeRxZXKkOJxfb/AfZ8ik5CfYJrxmTBuvGJqn8BvgJAAunBcvABWeLiRoRB5b4BcjoBw/4XQ bqA5wLwAkZGa8J/gKxDWZJKQqHBumjBkm4C8ALuf4ZigZqfwqgEuUW2F0MmXcGVcVfByeirynIDZ t3ByZ6JgL8FoLgM24PtUIJyAdjCZL1GhsKJg6XG/Q7AxITIV+XIwYlXwdzKj/TPUaivxObCTsCrx t8CsUOWEIHY8IHdromDboDXDT5iQoACMEVQgcGedg2U3l3A3NS5Qb6Hgn+Bsef50vCCiYC8wKlE4 x6HQt3D/oQCf4CshLXCh0KFBbrGuEP9DYFAwrrAtcJ/ALXBusTYh/56gONA2wZ9gqHCToTjBbrHv bqCdMS1wm0BrLnEvMLwA/T5Rd5SwOzKOYKLAoRCMgq+iYJiiPAGwgWZqgGyREc+5gJiwnyCUsHB1 QECh4P+zsEzQPkf2cpOAOHDhto5w/ndusatCkZBaCALwAf/CTkP+g8kDwkbCysFqAVCBacJ9g/mSe ko5xVCAqwTrQtUAvML9GMkaijILogUYkkWRjP3GfKlO7sLshoIBGMWx2lQD5SiF1Y47wSiKZ0G6g SrL/NiG4weEgNyE60ItBSeGggPZ0jpBWIC64NEo2hCBK0v8ssUs/TE9NX0qQaXCggJEQ7ysQTy9Q P1FPbFxwoIA9APdO71O/VMUpTaxfMFKPV3/9VKViYUBe0VivSmNiQFZP/1sfXC9dP0qBZVBekksf X///YQ9ZHX/QXp9kL2U/Zk9Kgf/7MGMvaM9p32rlNzCfoDfR/6NgomCeX59voH+hj4pvi39/jI+N moVgssmikC2A4Xpj51gwm/CriQ0Kb9J7dm/E/3CPcZVzBXQ+eLEAAXkHo29rdWG8AHBDUWZ5jUnj YohrbWtswyBfTbeBykFzMVNz4H1UtfBqgX+ywyYxqjD+YYCvgb96/l//iV+Kb4s6hTSAb4cPiB98 Ml+FT40Pjh+rxYUBIIRAZ6x1abtQe4VTK8Bpp/BbqEBaUGg6oT/gabjwLFggT2ZA8JigIEWAIPhD VE+MT5F/ko+Pf5CP45gvmT9FTUOav5vPdXDcc3WsUZzvq8Uylv+cL++hf5orQQK7EmZBIHmRRbAP os+j36TvrCBZUEVSwExJTksgIrdyc0CWOrdwlBNfc0BtQLRw9GMuteEior+ov6nPemjXz7EjYknj ZLigYUDzdSAGYnSQwHAgANDJ6gB5+brOEYyCAICqAEupCwIAtBAqA7QR4LMdNrQRbQAAYQBpAGwA dACIbwA6tbNnAHW18WByAGUAX7YztcBA47dRtcBjAC64UbfCtBD/TaCtUkEg9nBn4HimJjEugf+f T66/gnysH4URuTOtn7vPH6Ufmm+638CPgosrMSjpC/EpIO0RLdiwyfC/H//ET8Vfwkh8f3lwKzB9 r36//3jLyC/JP8pPy19xT3Jfc29/fvx5WQYmg0cqwYQs0kZ9AgDbUAAAAB4AcAABAAAARQAAAFJl Z3JldHMgdG9kYXkuICBDb250aW51YXRpb24gb2YgcGVyc29uYWwgYXBwb2ludG1lbnQgZnJvbSBs YXN0IHdlZWsuAAAAAAIBcQABAAAAFgAAAAHGjh2/F9p0W7uw30uKtA0NGebbpA0AAAMAJgAAAAAA CwACAAEAAAALAAEOAAAAAAIBCg4BAAAALgAAAAAAAABHAHgXx5CsSq/vC6ZaBRewAQD8FU3Y73V5 SocrBssEOJevAAAAA6wFAAAAAAMACVkDAAAAAwDeP59OAAACAX8AAQAAABEAAAAyMDkyNENCRjFE OEVDNjAxAAAAAAMABhANN8yOAwAHEE8AAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABQAAAAVE9N VE9NTUFHVUlSRVNFTklPUlRFQ0hOT0xPR0lTVCxPRkZJQ0VPRkNUT0VNQzJNQUdVSVJFVE9NQEVN Q0NPTSsxKDg0NSk3MjktNDgwNgCmag== ------=_NextPart_000_0000_01C68DFC.3851D580-- Ê0=0ŠÍºVðßäŒTþ"¬³rªU0 *H÷ 0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0 960129000000Z 280801235959Z0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority00 *H÷ 0å¿m£Va-HqögÞ¹ë· ú8%¯Fåsš $] Ìen°ÐV¡sßŽX9knÁöÕšš?ª1¬°4×4g ÍâNEVixÚÜG)»6Éc\Åà×-{¡·2°{0º*/1ªî£gÚÛ0 *H÷ L?žÆhßîC3]éŠËMz3ÿô6Ø"6hl|BÌó.Ä?°OÿvùâŒJéÍ ÷Å)ñ"]ž±Ý#£{%F0yøêKÂÈã·ô@<Ã_SèHäŽ{¡5°{%ºžÓ«?84óÑq0b0Ë ÚÁ?« tzŽÎ.30 *H÷ 0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0 980512000000Z 080512235959Z0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated00 *H÷ 0»ZD»Uýz-Ox6ž J²oT¿Œèw*¹ðh»Ù1ApzK¹HV-ÇáB«À¢«D\ªBðé/ûÂ;»ŸÉ' ]¶°6B3µnTOJ¿Úùè¶ãÌÆj$ãüàeº§±~ïÉÛ7jÈJÈ ä£°00U0ÿ0GU @0>0<`HøE0-0++www.verisign.com/repository/RPA01U*0(0& $ " http://crl.verisign.com/pca1.crl0U0 `HøB0 *H÷ }oEK8 žÞéSd!ŒäL+þ@¬Ø 9j¡2!,«YþÒb}U8°7sÜôfcbœáSpRçšØRé[-ªáÞÏ¬1TÔÈØ#šï+2},È|š.wòDÑe MtµîÓst.;5rç@1Ó²Ä«çVŸãû00 aI±thÆãøSÈ¬1ÌÀ .0 *H÷ 0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated0 060419000000Z 070419235959Z010U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)9810UPersona Not Validated1402U+Digital ID Class 1 - Microsoft Full Service10UThomas Maguire1"0 *H÷ maguire_tom@emc.com00 *H÷ 0«ŒåO!² cuû!ç_ãÚFÒWðçínøíy>ÏŒ³$"ÎñÜeq¶Úß©Çï«t úK?@K¬þ[REæâËH¶#»ÇS1w\¯lúèŸa7Š)ì_eÎËê66$±s²ùxT¿4×íËª/ç£µ0²0 U00DU =0;09`HøE0*0(+https://www.verisign.com/rpa0U 0U%0++03U,0*0( & $"http://crl.verisign.com/class1.crl0 *H÷ <¢A·ë¡ø'¿ÎáÜßTî$ñ<Ü{nDa6gWÛÈØ¿€«ÉšO³Eq!ÛÃnw) Žæ5ÜÊ£Á×eF¹Dö¬«úÄ()ÌLç£4œä×Å²AÿÅ,^56¥¢Ò°®oI÷ñ¿AÿæÅ1>0:0á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0 + ²0 *H÷ 1 *H÷ 0 *H÷ 1 060612124304Z0# *H÷ 1àÙu `(0Q·ûv{Ôç Ô0g *H÷ 1Z0X0 *H÷ 0*H÷ 0 *H÷ @0+0 *H÷ (0+0 *H÷ 0ò +71ä0á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0ô*H÷ 1ä á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0 *H÷ 3/ï{¿E©µN¡]×¢qŽæ)>4ñÚBó»7ºÙ!ZÁÊÙ$¥áW÷ÀTò3Kð#`£[€±üïŠmœÿNŠçpw".Æ×ÏIÁá5î?üÑ)Šÿ ôw!MBÒ¿k×ptý¿7 >yAË

1 0

Teleconference minutes - 8 June 2006
by Andreas Savva 09 Jun '06

09 Jun '06

Minutes attached. Also uploaded to the new gridforge https://forge.gridforum.org/sf/go/doc13592?nav=1 (Or go directly to the text view: http://tinyurl.com/et8te) -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 8 June 2006 ================================= * Participants Mike Behrens (R2AD, LLC) Dave Berry (NeSC) Michel Drescher (Fujitsu) Donal Fellows (UoM) Steven Newhouse (OMII) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Ellen Stokes (IBM) Jay Unger (IBM) Apologies: Tom Maguire, Hiro Kishimoto Minutes: Andreas Savva * June 1 minutes approved with no changes * Action Review: - Re-schedule the information model rendering discussion - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches - Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well Agreed to re-schedule the information modeling rendering discussion for June 19 (i.e., at the next information modeling discussion). Post positions to the list a few days in advance to allow a proper review. * July F2F update Discussed and revised the agenda to accomodate members dialling in from Europe and members that also have to attend the (co-located) GGF Management Committee meeting. Agreed that - BES will need half-a-day or more and should be earlier in the week. - Monday schedule cannot be changed - EMS & Data (incl. DMIS) topics should be in the morning so that members from Europe can also dial in [Revised agenda-at-a-glance (V3) sent to the list after the call.] * EMS Scenarios review Updated draft sent to the list. Included EPS scenario and ACS scenario. - Agreed that using BLAST as an example of a POSIX application is reasonable and may offer possibilities to illustrate the use of other 'resource' declarations in JSDL and CDL (e.g., the BLAST database as a resource) - The ACS scenario includes operation names. Doing so is good and should be extended to the other services, as far as operation names are known. For example, EPS does not have a formal specification yet so an approximation is the best that can be done. - For the ACS scenario the ApplicationVersion should be added as a term to match on. Also some description that resource requirements from JSDL may also have to be matched with resource requirements in the Archive. - OGSA data scenarios include an execution and staging scenario. It is still in draft. Dave B requested that the EMS team review and comment. - As future work there is a question on how CDDLM should interact with the data services. This was raised in a previous meeting (F2F). - Once the Scenarios draft is more presentable, request that the HPC Profile group review the scenarios relating to them. - For the final version 1.0 document the "Provisioning a BES instance" scenario may be left out. (It is still too abstract.) It may be added in a later version. - Discussed potential future work after the scenarios are done: - An EMS Architecture document along the lines of the Data Architecture document---more detailed version of the EMS Capability section from OGSA Architecture. Note that this is already on the list of OGSA-WG deliverables for this year. - Interactions/re-factoring between capabilities (e.g., between Data and EMS) ACTIONS: - EMS team to review data staging scenario (section 5 of https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-d-w…) - Add sequence diagrams to the scenarios: - Andreas will do the "Install application" scenario (3.1) - Mike will do the "Install application using ACS" scenario (3.3) - Other volunteers welcome. (Andreas will ask Donal for the EPS scenario) - Andreas will merge draft scenarios and sequence diagrams to the "EMS Architecture Scenarios" document

1 0

Agenda for June 8 call
by Andreas Savva 08 Jun '06

08 Jun '06

Hi all, The following is a proposed agenda for the OGSA call on June 8th, Thursday, from 8:30am to 10:30pm (CDT). (Sorry for the delay in sending this out.) Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0608 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (June 1st) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060601/en/1 Action Items status review (see the bottom of this email) Agenda bashing 2) July F2F update (20 min) Discuss tentative F2F agenda (attached) and new schedule requests (e.g., move BES session from Tuesday afternoon to some other time). 3) EMS scenario discussion (Steven and Andreas, 40 min) An updated draft including EPS scenario (Donal) and ACS scenario (Andreas) will be sent out before the call. 4) Wrap up (10 min) AOB <*NEXT CALL*> June 12 (Mon): CDDLM & EMS (Jun and Hiro) June 15 (Thu): Security & BSP Public Comments review (Frank and Takuya) Architecture & Glossary 1.5 (Andreas and Jem) June 19 (Mon): Information model (Ellen and Fred) Roadmap 1.1 (Hiro, ChrisJ, and Jem) June 22 (Thu): EMS scenarios (Steven and Andreas) June 26 (Mon): Security & BSP Public Comments review (Frank and Takuya) CDDLM & EMS (Jun and Hiro) <*ACTION ITEMS*> - Re-schedule the information model rendering discussion >From May 22 call - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches - Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well >From April 5 F2F meeting - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. Deferred - Frank to write up and send to the list a one page summary of the authorization call-out proposal. (April 24 call, postpone until June 14) - Jay check and find out relatively small funding to Globus to develop document on their security work (April 6 F2F) - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (April 4 F2F) -- Andreas Savva Fujitsu Laboratories Ltd

5 6

RE: EMS Scenarios draft 4 (was Re: [ogsa-wg] Agenda for June 8 call)
by Dave Berry 08 Jun '06

08 Jun '06

The data services scenario I mentioned on the call can be found in section 5 of https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa- d-wg/docman.root.working_drafts/doc13591. This is very much a work-in-progress. It would be really useful to have some comments on this scenario from the EMS point of view. Dave. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Andreas Savva > Sent: 07 June 2006 04:01 > To: 'ogsa-wg' > Subject: EMS Scenarios draft 4 (was Re: [ogsa-wg] Agenda for > June 8 call) > > > 3) EMS scenario discussion (Steven and Andreas, 40 min) > > An updated draft including EPS scenario (Donal) and > > ACS scenario (Andreas) will be sent out before the call. > > > I am attaching an updated scenarios file (draft 4) for review > tomorrow. > As last time this is a pdf file with a change-tracked MS Word > file inside. > > (I'll put this on the new gridforge after the transition is complete.) > > Andreas > > Andreas Savva wrote: > > Hi all, > > > > The following is a proposed agenda for the OGSA call on June 8th, > > Thursday, from 8:30am to 10:30pm (CDT). (Sorry for the delay in > > sending this out.) > > > > Dial-in numbers for Thursday: > > Free: +1-888-452-0308 > > Intl/Toll: +1-484-644-0505 > > PIN: 71815 > > > -- > Andreas Savva > Fujitsu Laboratories Ltd >

1 0

Regrets today; personal appointment
by Maguire_Tom＠emc.com 08 Jun '06

08 Jun '06

0 *H÷ 010 +0 *H÷ $Content-Type: multipart/mixed; boundary="----=_NextPart_000_005C_01C68ADE.5A80A170" X-MS-TNEF-Correlator: 50A08AE1FF8AC601 This is a multi-part message in MIME format. ------=_NextPart_000_005C_01C68ADE.5A80A170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tom _______________________________________________ Tom Maguire Senior Technologist, Office of CTO EMC2 maguire_tom(a)emc.com +1(845) 729-4806 ------=_NextPart_000_005C_01C68ADE.5A80A170 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IisNAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgAwDwAAHwAAAAsAHw4BABIAAgH4DwEAAAAQAAAAGTFs0enA QU+TG+xdGMv50gIB+g8BAAAAEAAAAEcAeBfHkKxKr+8LploFF7ADAP4PBQAAAAMADTT9PwUAAwAP NP0/BQACARQ0AQAAABAAAABUlKHAKX8QG6WHCAArKiUXHgD6PwEAAAANAAAATWFndWlyZSwgVG9t AAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAASAAwARgAggBgAAAAAAwAAAAAAAAEYA AAAAAYUAAAAAAABAABOACCAGAAAAAADAAAAAAAAARgAAAABghQAAAAjW6CkAAAALABCACCAGAAAA AADAAAAAAAAARgAAAAADhQAAAAAEgAsABoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAASAAwAD gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAGqACCAGAAAAAADAAAAAAAAARgAAAAAYhQAA AAAAAAsAcIAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAASAAgEJEAEAAAA3DAAAMwwAACAcAABM WkZ1HJwSsAMACgByY3BnMTI1GjIMYGMAUAEEc3Rz4mgFcGJjaA71CQAPh2ZoDeAPlmJpAUMLYG6R DhAwMzMRpmZlEiI/AfcCpANjAgAPgArAc2VCdALRcHJxMgAAKskKoW5vFOAgMAHQAdDCNhIwMDUw NBaxAdD5FqA0fQdtAoMAUAPUFI/9FZtiFnEW4BZCG4QXYAcT+QKDMzYY3xnvGvcWpBtiGRdhYWgD cQKDMjM4FxQeISMeMiAHbSBDRT0g1TkhXxbQIo8jlXlyzSDUNBjBFDwxNhjBJe/1A4JHCdFrJ2UO UCf/K0F7KT8DglQIcCdlElArbjeGNyyPI5QoSGViCXD8dyknZSWxLs4ifzDWBxDXAaAN4DG2NTJP OBzxM5/1A4JCB0B0DeAnZRzxKA4XLpE3PzEDVgiQdG5h/QeBZTG2IUEdLCJYBxMj5740JIE9bSWn PuUnRjUYz/8o6D7kKokOQUKvLHY+5C33vjUukUK9L7c+5DFMNSWx90g+Pmw07DU10UK9Nvc+5D04 ijUc/zpoSbU8HjU5/z0/IlkggyPmVAA/3yWZVeX/J0UWgEKPKOlV5CqIFoBFX/8sWVXkLfYWgVyP L7hV5DFL/xtBX08zWGD1NPoWgE4PNun/VeQ4iRaAUO86aWD1PB4WgK8vwVRdbKBgfVQdoGkxsasC kQjmOwlvMG7vZU3h/3AaTeJw/3IIcARN4nCPdF+fdB1zn3HPcB8S8DI4eer/ewF6v3vJcAR78npf fi997fd9b3uff2Q5DlCCtIQRfDOnhBACgg8QeWwHkGgJ4Op0AABxAyFsEYEFEAFAYQPwZGN0bAqx AGBzjwqwh1AdoIeSbnVtAgAgYWF1dG8AYGRqxnUPEAUQZ2h0hrEKAcuGgAoBaQGQcDADsiewf4Zw EfYSqAjQCcCHEIsjbg5wi3mNFAMwc25leD8d8AewBbAAwAJzFaBjc5cSIAMwiRBkinBpdhYQcw8A HdBtaRDAkAAJ8CBORAEQiMA4oCBQCsBh4wnAipBoIEYCIY80DyDuMQBQDyADYHcLMIlgAYDEc1eH EHRoQhJQiWC7CrCQAGwSICFAlKRylRivEACUhgGAlodilodylIHxBPBlbGyHAZRQk/EBQP8PIJBQ ACA4kZMBMXCVoJoGPwlQmiQMsZozh4CaJGRn15sGnICcBmiaFXYDMIZP/4dfiG+Jf4qHojER84sF EuL/iwGMfKPHpUSORZMwkHyO1OtVwQJgZY83NY/akZAI0PshEI5BYp/QCYACII+yhYFXHcCfQCjg N4QAOGuAIHhIeXAEkIohKsOPczb/qU+rEqqfq6iScJjAk5AJgP+sTy+gj9oYswwBrm+Qmg8APaxh cwIgPxEPAAWgbXDbFfKvb0UAwAMQU4WSL6D3bhMVoAtgdAnwDyCFk56gzHNkDxAHcGF4qSBoQNu5 kRARawmAAQEwj0NvAGJ2AlEge1WssBXgd18YYbs0q4G7srzTODXAMfclsKtybKA3DkAAUKtyJ8De MBYwaEC+wyxgN1bBq3L9AcA4M1Ce0auBhBBrgL5gv7zTEiDAYSfBq3M5QDM9IP8SUKtzR/CEAFDR wwRUEE3wd8AEM0F8gDPBZb/gFtA3+8Olv+E2xODBdMWgxOG99O+EAb8gOnHGxDarwMOVvpCtlRE2 wAS+kDnCsDm+pH9soBaiyOUugKwAyxbF0DfvFrDABBagVsA5NcHMw7/B/xJAv1TFEDIgDkC99CEw NvD+NkfxzwTKIEJwIUC+xFxR/jnBZCswq9A1wNEnyMHNZP05QDbFwM1VPSBN8DNQvqX/wIEWgNBl ylDIoFQR1QXDgP8MAatyywE1wNEVFsDE0cpV/03wR+HKINZ00yDFoL/g1nT/zHDE4MaA1nTC0BJA L7HaRP9K8AHAzWQo8MLQUNDGpNMg/9AQqSDBZM+A0/EBwNu0xaD/zRAhMcAjlSBUEMLVq9DN8P8n wMakzfBlMduVzpDREC+g/8C0xdDJceDWKPCEAd6lrAD9LoAx32VWwM3wzpC9ZMEx/9EQwLTC0MWg FqDBZDbwUND/5IfPgMXQzhXPUcogXGHnxP+/4BJA5WXKIL/gTfHA0xaw/9qhvfTqQc3ww5XKICEg JHD/6eWr0BahwWYSMM6QKPHBhP824NxBxqXuIdnR0GSjolQB/8dl46FUANBVEiDZARZwxGX/a4DR 0NEQzWSVETXAEjDvVf/y8jIgwiUSIM1AKPDylZMw/zlA6MHzdXyAvpDOFZMwTfD/KzDBVtDR1hHC 5QHQxOHvRv++kOFRxcD4Vb5hlRL6BdQQ/8cR+FXOAcogxGUnsAHAwrD/8pVCYc6QvpUOINzBUND9 9v/UodAQx2V8gBbQw4cAAdSS//+mNcA/wPxWwIDCsPG2w2H/0DBK8QL05dG9wQLlQnBCcP/sFQTR DjHF1tAwwID38QSG/4QQ/aEC5fzgwqEC1tEQ9aH/xGUW4MOBFuDCNeYBq9AKJ//agKvACVYXAeaB C9bdAQEm/7+x5dEKJsaAuiHC5T/A1MH/6RWpIM0QzGHC5tGxVAAP1v8hIM+Awte/QM0h71VFQAdx /+hVqSAW4L2w+qZN8OmhDib/UNDF0IQQxGXyUUJw0DDC9f/UEMIBw6fKIM+GLFHl8YQR/6t0z4AZ QcOlyKDcAb9Fq7Y+fZ8ik5CfYJrxmTBuYl5qn8BvgJAAuqBcHtB4q7jBoRB5b4BcjoBwhdB/bqAo QLwwkZGa8J/gHZBk65KQqHBumjBkm4C8MJ/h3ZigZqfwqgEg0W2F0Jdw5GVcVfByeh1ynIC3oOxy Z6JgIkFoIIM24G8w/ZyAdiMZIdGhsKJg4YFDsN8joSSV8AIi4lXwdyUjJlT+ah5xK6CTsB1xt/Cs YCtA8nY8IHdromDWsChDmJCnoACMEW8wcGedg2WXcBsptSDQb6Hgn+BseXT/vFCiYCGwHNErR6HQ t6ChAP+f4B2hH/Ch0KFBbrGuIENg/zigrsAf8J/AH/BusSihnqD/K1ApQZ9gqHCToStBbrFuoPed MR/wm0BrIPEhsLwwMNH+d5SwLbKOYKLAoRCMgqJg15iiLoGwoWY8IGyREbmw55iwnyCUsHB1MsCh 4LPQ/0zQMMftAjmAKvCrth2gSmD/brGrQpGQWgC8MH/wk5Cg8n8zcJGwstBDcG8wQ2CfYGT/npKO cW8wHUEtULVgIbA4wt85MoyC4JE4tJFkYzHxHNPPu+C7UaCAOMFsdpUAPLH8dWOO8DyymdBuoD1C KKF/uPH84CmhLVCLQTxxoIB0+46QViAuuGQ8xlxwqPWIfMf89zz7fP+89IFIQoICREB2Q90G/Qs9D 32xiQKCAL4BBf/tGT0dVKUA8ZVBFH0oPRzX+YmFAUIFLPzzzaEBI302v/06/T889EWuQUSI9r1KP U5//S61/0FEvVr9Xz1jfPRHxwP9Vv1tfXG9ddSmwn6AqUaNg/6Jgnl+fb6B/oY+Kb4t/jI//jZqF YLLpopAgAKt6j4BKwPOb8KuKDQpiYm4mYlRjH/9kJWWVZs5rQfaRa5ejb2fxNbwwcDXRZmwePHNi a0Rta19TIF9Nt7FB5WXBU2ZwfVS2EGGRsuO/F+GqMPTxc190b22fX3wv/30/fgp39HMfec96327T eA8vf9+A76vGd8EgdwBnddZpu4BuNVMeQGmn8KhALUzgaC0hMmBpuSAsICxPZjNwmKAgOBAgQ/xU T38fhF+Fb4JPg1+LD3OMH7dxTUONv47PaABz7nWsYY/vq8Yyie+PL5SP940cM4K7QmYzoGwhOECV 7weW/5gPrCFZUEVSTGBJTksgIreiZdA6S7eghwNfZdBtQKdAY/outgEild+b75z/bPnv0WsV4jxz ZLjQYTNzZ7BiA2cgAfAgANDJ6nkA+brOEYyCAKpAAEupCwIAp2ADFadh4KZtNqdhbQBhAABpAGwA dABvRAA6qQNnAHWpQXKwAGUAX6mDqRBAqqHxqRBjAC6roasSp2BiQP+gkjOg7QBacGs2F+EhAZJf /6H/dS2fX3fRrIOg368fmD+PjV+uH7PfdS0rMSi9sfQpIOUhLcLAyACyf7e//7jPtalvL2wAHbBw X3Fva1v/u6+8v73Pvt9jz2TfZe9xnT9r6vv1dgcdQXbsxeZ9AAHO8AAeAHAAAQAAACQAAABSZWdy ZXRzIHRvZGF5OyBwZXJzb25hbCBhcHBvaW50bWVudAACAXEAAQAAABYAAAABxor/4RylYmCaddVJ o4uQp9NmNjHNAAADACYAAAAAAAsAAgABAASACwABDgAABIACAQoOAQAAAC4AAAAAAAAARwB4F8eQ rEqv7wumWgUXsAEA/BVN2O91eUqHKwbLBDiXrwAAAAOsBQAAAAADAAlZAwAAAAMA3j+fTgAAAgF/ AAEAAAARAAAANTBBMDhBRTFGRjhBQzYwMQAAAAADAAYQDTfMjgMABxBPAAAAAwAQEAAAAAADABEQ AAAAAB4ACBABAAAAUAAAAFRPTVRPTU1BR1VJUkVTRU5JT1JURUNITk9MT0dJU1QsT0ZGSUNFT0ZD VE9FTUMyTUFHVUlSRVRPTUBFTUNDT00rMSg4NDUpNzI5LTQ4MDYAhSo= ------=_NextPart_000_005C_01C68ADE.5A80A170-- Ê0=0ŠÍºVðßäŒTþ"¬³rªU0 *H÷ 0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0 960129000000Z 280801235959Z0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority00 *H÷ 0å¿m£Va-HqögÞ¹ë· ú8%¯Fåsš $] Ìen°ÐV¡sßŽX9knÁöÕšš?ª1¬°4×4g ÍâNEVixÚÜG)»6Éc\Åà×-{¡·2°{0º*/1ªî£gÚÛ0 *H÷ L?žÆhßîC3]éŠËMz3ÿô6Ø"6hl|BÌó.Ä?°OÿvùâŒJéÍ ÷Å)ñ"]ž±Ý#£{%F0yøêKÂÈã·ô@<Ã_SèHäŽ{¡5°{%ºžÓ«?84óÑq0b0Ë ÚÁ?« tzŽÎ.30 *H÷ 0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0 980512000000Z 080512235959Z0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated00 *H÷ 0»ZD»Uýz-Ox6ž J²oT¿Œèw*¹ðh»Ù1ApzK¹HV-ÇáB«À¢«D\ªBðé/ûÂ;»ŸÉ' ]¶°6B3µnTOJ¿Úùè¶ãÌÆj$ãüàeº§±~ïÉÛ7jÈJÈ ä£°00U0ÿ0GU @0>0<`HøE0-0++www.verisign.com/repository/RPA01U*0(0& $ " http://crl.verisign.com/pca1.crl0U0 `HøB0 *H÷ }oEK8 žÞéSd!ŒäL+þ@¬Ø 9j¡2!,«YþÒb}U8°7sÜôfcbœáSpRçšØRé[-ªáÞÏ¬1TÔÈØ#šï+2},È|š.wòDÑe MtµîÓst.;5rç@1Ó²Ä«çVŸãû00 aI±thÆãøSÈ¬1ÌÀ .0 *H÷ 0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated0 060419000000Z 070419235959Z010U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)9810UPersona Not Validated1402U+Digital ID Class 1 - Microsoft Full Service10UThomas Maguire1"0 *H÷ maguire_tom@emc.com00 *H÷ 0«ŒåO!² cuû!ç_ãÚFÒWðçínøíy>ÏŒ³$"ÎñÜeq¶Úß©Çï«t úK?@K¬þ[REæâËH¶#»ÇS1w\¯lúèŸa7Š)ì_eÎËê66$±s²ùxT¿4×íËª/ç£µ0²0 U00DU =0;09`HøE0*0(+https://www.verisign.com/rpa0U 0U%0++03U,0*0( & $"http://crl.verisign.com/class1.crl0 *H÷ <¢A·ë¡ø'¿ÎáÜßTî$ñ<Ü{nDa6gWÛÈØ¿€«ÉšO³Eq!ÛÃnw) Žæ5ÜÊ£Á×eF¹Dö¬«úÄ()ÌLç£4œä×Å²AÿÅ,^56¥¢Ò°®oI÷ñ¿AÿæÅ1>0:0á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0 + ²0 *H÷ 1 *H÷ 0 *H÷ 1 060608133143Z0# *H÷ 1Õ¡Ø²æû)nYì-0g *H÷ 1Z0X0 *H÷ 0*H÷ 0 *H÷ @0+0 *H÷ (0+0 *H÷ 0ò +71ä0á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0ô*H÷ 1ä á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0 *H÷ _*òöãÖÎØ{³=Ûv#÷ÔÔ4Œ¹ÀéÇÁý|ïÒ á_Ïf<tR õª4ãÇ`]Ðjû?åñ&ÜúUïE"Ä|Dhªê?åNÒû ©æéB2i0áõW¶âøŠð_ðG£)þ{øæ$(è×

1 0

OGSA Roadmap Editors Conference Call tomorrow
by Christopher Jordan 07 Jun '06

07 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If you are already involved in the OGSA Roadmap document editing process, or are interested in becoming involved, please join me for our inaugural conference call on Wednesday June 7th, 15:00PM PDT/ 18:00PM PDT/2100 London time - this is Thursday June 8th, 7:00AM Tokyo, 6:00AM Beijing. Meeting Title: OGSA Roadmap Editing Duration: 1 Hour 30 Minutes To Join Audio Conference Primary Dial-In: 1 (800) 559-0817 Alternate/International Dial-In: 1 (630) 424-8578 Passcode: 8820079# I will put together an agenda for this call and send it out tomorrow morning - please send any topics you'd like to discuss to me directly ASAP. Also, we are fast approaching a deadline for anyone who wishes to participate in this process. It is not necessarily mandatory that you attend the conference call tomorrow if you want to participate, but by the time we have the second call, I probably won't want to add any more participants, in order to keep the process moving along smoothly. Don't let this necessarily discourage you from joining the process, either - we'll need all the help we can get, we just need it sooner rather than later :-) Thanks. - ---------------------------------------------------- Chris Jordan HPC Systems Engineer High End Computing Systems Group San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEhi1IPCVtcXn6kg8RAkddAKDN2Hzx8i/UXvCB1RHz/gGj6Rd/1gCgi6wN KT3aevBJ1Rz1XJU26uU8nWI= =WmAG -----END PGP SIGNATURE-----

1 0

Proposed agenda for June 5th call
by Hiro Kishimoto 05 Jun '06

05 Jun '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on June 5th Monday from 5pm to 7pm (CDT). The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0605 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (June 1st) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060601/en/1 July F2F update if any Action Items status review (see the bottom of this email) Agenda bashing 2) Information model (Ellen and Fred, 60 min) - Information Modeling in OGSA - Position Paper https://forge.gridforum.org/projects/ogsa-wg/document/Info_Model_position_p… - BES Information Model https://forge.gridforum.org/projects/ogsa-wg/document/BES_info_model > The main issue discussed was the difference between the approach > proposed for a (minimal/)general element that can be used to > express <name,value> pairs, with the value part being typeless VS > extension using an xsd:any and defining a schema. > - (See also minutes of GGF17 and April 27.) > - There has been experience with both approaches > - Difference is relying on explicit typing vs convention; and > checking types when validating vs matching time (fail in a subtle > fashion) > - Discussed whether stronger typing with a schema makes for easier > checking. Having an xsd:any doesn't help as much as people might > think for checking types; matching might still fail later. > - It is still necessary to define conventions. Need to define a set > of <name,value> conventions > - Andrew's issue is whether the value (in (<name,value>) is typed. > - Type checking information is needed somewhere; and wouldn't > want to have it only in the code > - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) > to get feedback on pros / cons of the two rendering approaches > - Jay is following up. He has a meeting (6/12) with Miron and will > arrange to get some feedback; but probably not by next call. > > - Darren/Andreas will take the Modeling position paper and discuss > it within the JSDL-WG as well From April 24 call > - No JSDL call yet. 3) Wrap up (10 min) AOB <*NEXT CALL*> June 8 (Thu): EMS scenarios (Steven and Andreas) June 12 (Mon): CDDLM & EMS (Jun and Hiro) June 15 (Thu): Security & BSP Public Comments review (Frank and Takuya) Architecture & Glossary 1.5 (Andreas and Jem) June 19 (Mon): Information model (Ellen and Fred) Roadmap 1.1 (Hiro, ChrisJ, and Jem) June 22 (Thu): EMS scenarios (Steven and Andreas) June 26 (Mon): Security & BSP Public Comments review (Frank and Takuya) CDDLM & EMS (Jun and Hiro) <*ACTION ITEMS*> From May 22 call - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches - Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well From April 5 F2F meeting - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. Deferred - Frank to write up and send to the list a one page summary of the authorization call-out proposal. (April 24 call, postpone until June 14) - Jay check and find out relatively small funding to Globus to develop document on their security work (April 6 F2F) - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (April 4 F2F) -- Hiro Kishimoto

1 1

gridforge screwed up?
by Frank Siebenlist 05 Jun '06

05 Jun '06

It seems our dear forge.gridforum.org has been "upgraded" and "improved"... i cannot login and links have disappeared :-( -Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 1

Teleconference minutes - 1 June 2006
by Andreas Savva 02 Jun '06

02 Jun '06

Attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060601/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 1 June 2006 ================================= * Participants Jay Unger (IBM) Frank Siebenlist (ANL) Andreas Savva (Fujitsu) Tom Maguire (EMC) Hiro Kishimoto (Fujitsu) Chris Jordan (SDSC) Donal Fellows (UoM) Michel Drescher (Fujitsu) Minutes: Andreas Savva * May 25 teleconference minutes approved with no changes * Basic Security Profile public comments status - Some comments received from Von Welch - The public comment period runs to June 20. * Review of Action Items (Only items with updates are listed.) - The chairs to send out what registration is needed to enter ANL for the F2F. - Hiro has sent a mail to the list with details on how to register. - Ian has booked the meeting room. Also a block of rooms has been reserved at the Argonne Guest House. - The group will split the cost of refreshments. Jay will talk with Steve Tuecke if it's possible for someone coming in from the outside to pick up coffee etc. - No security session at the F2F since Frank is on vacation. - Andreas to ask CDDLM (actually Jun, Hiro) for the corresponding CDL documents - Email sent. (Closed) - Check whether CDL documents are available at next document review. - Andreas will talk with the ACS chair and draw up a first draft of interaction for review. - Working on draft scenario. (Closed) - Check draft scenario at next document review. - Donal to refine step 1 and 2 to show the RSS interaction - Donal to change the source/target urls in the JSDL example to use remote resources. - Draft received. (Closed) - Andreas will merge in new draft. Check at next document review. - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches - Jay is following up. He has a meeting (6/12) with Miron and will arrange to get some feedback; but probably not by next call. - Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well From April 24 call - No JSDL call yet. - Frank to write up and send to the list a one page summary of the authorization call-out proposal. - Today's agenda item. * OGSA authorization call-out proposal review - Frank submitted a proposal to the XACML group. They discussed it and decided to follow a different approach. Frank forwarded an email describing the XACML group's decision. - (The SAML profile defines the format on the wire when the request is remote. The local case is considered internal and left up to the implementation.) - Frank is now consulting with people in GGF (David Chadwick, Von Welch) on whether his approach can be defined within the AuthZ group. If there is no agreement then he will accept the XACML group's decision. - Review status again on the June 15 teleconference. * OGSA document schedule review (Hiro 30 min) - Reviewed Hiro's proposal. Agreed to all changes with the following amendments: - BSPs - move expected publication date to August - Guidelines document: fix typo 2000-07 -> 2006-07 - Agreed to delete the Information/monitoring document since there is no plan to work on this now. * Architecture 1.5 status - Document came out of public comment with no comments. Two minor comments since. - Andreas has received permission from Geoffrey Fox to use his presentation from the GGF17 panel as a public comment. He will post a link to it and review it separately. - Also a small number of people have been asked to review the document but there are no positive replies yet. - Discussed what to do if no more comments are received. Agreed that since this is a minor revision a second round of public comment is not necessary. The group will make whatever minor changes are needed and submit the document to the GGF Editor. - The glossary has more comments but it expected that if no other comments are received the documents can be revised and re-submitted in June.

1 0

[Fwd: Re: [xacml] Minutes of the 25 May, 2006 TC meeting]
by Frank Siebenlist 01 Jun '06

01 Jun '06

FYI - Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

Visitor's info for July F2F
by Hiro Kishimoto 01 Jun '06

01 Jun '06

Hi all, > - The chairs to send out what registration is needed to > enter ANL for the F2F. Ian is kind enough to reserve conference room and block guest rooms for July F2F meeting. Attendees: (1) Please fill out attached form and send it to valentin(a)mcs.anl.gov ASAP. (2) Make your reservation at Argonne Guest House (http://www.aps.anl.gov/travel/anlghhome.html) through web form; http://www.aps.anl.gov/travel/accomodation-form.html or call (630)739-6000. Argonne Contact Person: Ian Foster Argonne Contact Telephone Number: +1-630-252-4619 Argonne Contact Division/Department: DSL MCS Thanks, -- Hiro Kishimoto

1 0

OGSA document schedule
by Hiro Kishimoto 31 May '06

31 May '06

Hi all, > 3) OGSA document schedule review (Hiro 30 min) > Review progress of working documents > New OGSA documents proposal > - Hiro will send out proposal before the call > Update GridForge live charter GFSG asks us to keep "WG live charter" up-to-date. I update information for your review. You can see our live charter at; http://www.ggf.org/gf/group_info/charter.php?review&group=ogsa-wg Attached is pdf file of this page with mark-up. The following is the summary of my updates; (1) Group Summary I've copied text from GridForge Project page. (2) Charter Focus/Purpose and Scope I've copied text from GridForge Project page. (3) Exit Strategy I've copied text from our charter document. (4) Goals/Deliverables (OGSA 1.5 and Glossary 1.5) Add completed date for "public comment ready" Update due date for "publication" (5) Goals/Deliverables (OGSA Information/Monitoring Architecture) I propose to delete this deliverable. (6) New Goals/Deliverables - OGSA Basic Security Profile 1.0 – Core - OGSA Basic Security Profile 1.0 – Secure Channel - Defining the Grid: A Roadmap for OGSA Standards 1.1 - Guidelines for Information Modeling for OGSA Entities - EMS container information model profile 1.0 - OGSA EMS Architecture Scenarios 1.0 - OGSA EMS Architecture 1.0 Thanks, -- Hiro Kishimoto

1 0

Proposed agenda for June 1st call
by Hiro Kishimoto 30 May '06

30 May '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on June 1st Thursday from 8:30am - 10:30am (CDT). Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0601 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (May 25) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060525/en/1 BSP Public Comments status check Action Items status review (see the bottom of this email) Agenda bashing 2) OGSA authorization call-out proposal review (Frank 20min) >> Frank to write up and send to the list a one page summary of >> the authorization call-out proposal. Frank has been exchanging private emails with some of the xacml-tc members about the xacml-3 approach for the call-out to get a feel for the effort involved. He is not very happy with their model and he is trying to convince them to do the "right thing". If he does not succeed, then he will discuss with the authz-tc (WG?) members whether they want to define their own, non-xacml-3 compliant interface instead. 3) OGSA document schedule review (Hiro 30 min) Review progress of working documents New OGSA documents proposal - Hiro will send out proposal before the call Update GridForge live charter 4) Architecture 1.5 discussion (Andreas 20 min) Status review 5) Wrap up (10 min) AOB <*NEXT CALL*> June 5 (Mon): Information model (Ellen and Fred) June 8 (Thu): EMS scenarios (Steven and Andreas) June 12 (Mon): Security & BSP Public Comments review (Frank and Takuya) CDDLM & EMS (Jun and Hiro) June 15 (Thu): Architecture & Glossary 1.5 (Andreas and Jem) June 19 (Mon): Information model (Ellen and Fred) Roadmap 1.1 (Hiro, ChrisJ, and Jem) <*ACTION ITEMS*> From May 25 call - The chairs to send out what registration is needed to enter ANL for the F2F. - Andreas to ask CDDLM (actually Jun, Hiro) for the corresponding CDL documents - Andreas will talk with the ACS chair and draw up a first draft of interaction for review. - Donal to refine step 1 and 2 to show the RSS interaction - Donal to change the source/target urls in the JSDL example to use remote resources. From May 22 call - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches - Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well From April 24 call - Frank to write up and send to the list a one page summary of the authorization call-out proposal. From April 5 F2F meeting - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. Deferred - Jay check and find out relatively small funding to Globus to develop document on their security work (April 6 F2F) - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (April 4 F2F) -- Hiro Kishimoto

1 0

Teleconference minutes - 25 May 2006
by Andreas Savva 29 May '06

29 May '06

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060525/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 25 May 2006 ================================= * Participants Donal Fellows (UoM) Michel Drescher (Fujitsu) Chris Jordan (SDSC) Steven Newhouse (OMII) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Ellen Stokes (IBM) Jay Unger (IBM) Apologies: Hiro Kishimoto Minutes: Andreas Savva * Summary of Actions ACTION: The chairs to send out what registration is needed to enter ANL for the F2F. ACTION: Andreas to ask CDDLM (actually Jun, Hiro) for the corresponding CDL documents ACTION: Andreas will talk with the ACS chair and draw up a first draft of interaction for review. ACTION: Donal to refine step 1 and 2 to show the RSS interaction ACTION: Donal to change the source/target urls in the JSDL example to use remote resources. * Telecon minutes (May 22): approved with no changes * Action Items: No updates * OGSA-WG Summer F2F meeting Discussed and confirmed the choice of location (Chicago, ANL) and dates (July 17-20). - Expecting participation of Globus and Univa representatives. - Steven Newhouse cannot attend in person (Grid School). EMS discussion is set for Tuesday morning, which is good as it allows him to dial in. - DMTF alliance meeting: Ellen has arranged for the GGF meetings to be on Thursday so she can participate in the F2F until Wednesday. - Everyone intending to participate should send passport details to ANL. US citizens are better off sending their details also as it speeds the entry process. ACTION: The chairs to send out what registration is needed to enter ANL for the F2F. - Agenda corrections: - "GGF18 planning" on Thursday * EMS scenario discussion - Andreas sent out updated draft before the call. - Where do licenses fit in this scenario? - Scenario is intended to work out relationship between JSDL and CDL, so licences are not a part of it. (Could deal with them in a number of different ways: reserve/allocate before installing the software. Floating licenses might mean no delay at installation but cause a wait at runtime) - BLAST may not be appropriate example - The text is already changed to empasize that BLAST is an example. Better suggestions welcome. - There are 3 empty sections where the CDL should go. It is not necessary to have the entire component definitions, just the top level document. - ACS interaction should be added (separate scenario). Some points where it should fit in have been highlighted. The plan is to have a first draft of the entire scenarios document (up to and including cddlm interaction) by the July F2F and review it with the intention of submitting to GGF as an informational document. ACTION: Andreas to ask CDDLM (actually Jun, Hiro) for the corresponding CDL documents ACTION: Andreas will talk with the ACS chair and draw up a first draft of interaction for review. ACTION: Donal to refine step 1 and 2 to show the RSS interaction ACTION: Donal to change the source/target urls in the JSDL example to use remote resources. * OGSA document schedule review Deferred since no proposal was sent to the list.

1 0

No call on May 29th
by Hiro Kishimoto 27 May '06

27 May '06

Hi all, Since upcoming Monday is US holiday (Memorial day), we have no call on May 29th. Next call is June 1st Thursday. Enjoy your holiday! -- Hiro Kishimoto

1 0

Proposed agenda for May 25th call
by Hiro Kishimoto 25 May '06

25 May '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on May 25th Thursday from 8:30am - 10:30am (CDT). Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0525 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (May 22) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060522/en/1 Action Items status review (see the bottom of this email) Agenda bashing 2) OGSA-WG Summer F2F meeting (30 min) Tentative plan is the week of July 17th in Chicago (ANL). Hiro will send out survey result and session agenda proposal before the call. 3) EMS scenario discussion (Steven and Andreas, 40 min) Andreas will send out updated draft before the call. 4) OGSA document schedule review (30 min) Review progress of working documents New OGSA documents proposal - Hiro will send out proposal before the call Update GridForge live charter 5) Wrap up AOB <*NEXT CALL*> May 29 (Mon): No call (Memorial day) June 1 (Thu): OGSA authorization call-out proposal review (Frank) Architecture 1.5 (Andreas) June 5 (Mon): Information model (Ellen and Fred) June 8 (Thu): EMS scenarios (Steven and Andreas) June 12 (Mon): Security & BSP Public Comments review (Frank and Takuya) CDDLM & EMS (Jun and Hiro) June 15 (Thu): Architecture & Glossary 1.5 (Andreas and Jem) June 19 (Mon): Information model (Ellen and Fred) Roadmap 1.1 (Hiro, ChrisJ, and Jem) <*ACTION ITEMS*> From May 22 call - Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches - Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well From April 24 call - Frank to write up and send to the list a one page summary of the authorization call-out proposal. From April 5 F2F meeting - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. Deferred - Jay check and find out relatively small funding to Globus to develop document on their security work (April 6 F2F) - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (April 4 F2F) -- Hiro Kishimoto

2 2

Proposed agenda for May 22nd call
by Hiro Kishimoto 24 May '06

24 May '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on May 22nd Monday from 5pm to 7pm (CDT). The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0522 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (if available) GGF17 session minutes approval Action Items status review (see the bottom of this email) Agenda bashing 2) OGSA-WG Summer F2F meeting (20 min) Tentative plan is the week of July 17th in Chicago. Hiro will launch new zoomerang survey shortly. Andreas will setup gcalendar shortly. 3) OGSA telecon schedule (10 min) Hiro will send out telecon schedule proposal. 4) OGSA Information Model (Ellen and Fred, 30 min) Ellen will revise her modeling proposal. You can download current material from here; - Information Modeling in OGSA - Position Paper https://forge.gridforum.org/projects/ogsa-wg/document/Info_Model_position_p… - BES Information Model https://forge.gridforum.org/projects/ogsa-wg/document/BES_info_model 5) RNS document discussion (Chris Jordan, 20 min) Manual uploaded revised RNS document after GGF17. https://forge.gridforum.org/projects/gfs-wg/document/Resource_Namespace_Ser… Please read this document in advance and ask any questions to Chris and another GFS folks. 6) OGSA glossary document process (Jem and Chris Jordan, 30 min) Jem will explain expected contents and process proposal to new editors (Chris, Dona, and Andrew) 7) Wrap up AOB <*NEXT CALL*> May 25 (Thu): OGSA EMS architecture scenarios (Steven), OGSA authorization call-out proposal review (Frank) <*ACTION ITEMS*> From April 24 call - Frank to write up and send to the list a one page summary of the authorization call-out proposal. From April 5 F2F meeting - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. Deferred - Jay check and find out relatively small funding to Globus to develop document on their security work (April 6 F2F) - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (April 4 F2F) -- Hiro Kishimoto

2 4

Roadmap Editor organization
by Christopher Jordan 23 May '06

23 May '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I took a first pass over the "activities going forward" list, and it occurs to me that the optimal strategy for the moment would be to try and break these out to specific action items - these can be very high- level actions at first, with increasing levels of refinement as we understand the problems more. I suggest that everyone who intends to participate in the editing process read the current 1.1 draft document and spreadsheet, as well as the "going forward document from Jem Treadwell". All of these are available from: https://forge.gridforum.org/docman2/ViewCategory.php? group_id=42&category_id=945 For example, one of the tasks is to review the tracker items with respect to the current document and decide how we will respond or alter the document based on the trackers. I will take this as an action item. Another is to review and update the status of the various OGSA documents, including newly-added documents-in-progress. This might be a good task for Dona. I can also take the action of reviewing the various text sections and updating them to correspond with the information gathered by Dona, and whoever else works on it. These seem to be the largest and most important tasks, and the ones I felt comfortable taking or assigned. Please review the activities document and let me and Jem Treadwell, at least, know if you are interested in taking on any of the additional items, or if you'd be interested in helping with some of the high-level tasks mentioned above. I'm happy to give regular status reports and have some public discussion on the ogsa-wg e-mail forum, and on the conference calls, but I'd also like to keep most of the editor-specific traffic off the big mailing lists, if possible. We've tentatively chosen Wednesdays at 3PM PDT/6PM EDT as the time for conference calls related to roadmap-editing discussions. I think tomorrow may be too soon to start really having detailed discussions, but if I don't hear from anyone else maybe just Dona and I can speak on the phone for a few. Then let's plan on beginning official calls two weeks from now (Jun 7th), when Dona has returned from vacation, and we will communicate via e-mail in the meantime. Is this ok with everyone? Please note that I'd like to move quickly to assign tasks and begin making progress on this, as it seems that it will be a large, complicated task. If you are seriously committed to participating in the document editing process, please speak and participate soon, as at some point I think we have to close the door to new volunteers, just for the sake of efficiency.. Suggestions, opinions, rebuttals? - ---------------------------------------------------- Chris Jordan HPC Systems Engineer High End Computing Systems Group San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEc3mZPCVtcXn6kg8RAqy5AJ9uom1PmZwCaaFMJ/dxTOG3wJyzBQCdG/r8 PZD7+fzSxRKk0xDs9fGCCHo= =//bp -----END PGP SIGNATURE-----

1 0

Roadmap activities document uploaded
by Treadwell, Jem 23 May '06

23 May '06

Hi, as agreed at yesterday's meeting I have uploaded the Roadmap "next steps" document. The Roadmap 1.1 folder is at: https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&categor y_id=945 or http://tinyurl.com/aez86 - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com>

1 0

Teleconference minutes - 22 May 2006
by Andreas Savva 23 May '06

23 May '06

Attached. Gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060522/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 22 May 2005 ================================= * Participants Dona Dickinson (Northrop Grumman) Andrew Grimshaw (UVa) Chris Jordan (SDSC) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Mark Morgan (UVa) Darren Pulsipher (EMC) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Ellen Stokes (IBM) Jem Treadwell (HP) Jay Unger (IBM) Minutes: Andreas Savva * Summary of Actions ACTION: Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches ACTION: Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well * May 18 Minutes approved with changes - Delete Dona Dickinson from the participants list. * GGF17 minutes (EMS, Information Model) approved with no changes * Review Action Items: No changes in status * OGSA-WG Summer F2F meeting - July 17 at Chicago (ANL) seems to be the best choice - Strong preference for a 3 1/2 day meeting - Is there an agenda or list of topics identified? Hiro has received a number of requests already and will put together a list. - It is the same week as the DMTF Alliance week. Ellen is trying to arrange for the GGF activities to be at the beginning or end of the week - Marvin Theimer can only make Monday * OGSA telecon schedule Hiro sent out telecon schedule proposal. Identified topics and divided by day making them more convenient to main participants for each topic. Minor changes made for the following US holidays: - May 29 is Memorial Day: no call - July 4 is Independence Day: no call on July 3 and move agenda to July 10 An OGSA-WG google calendar has been setup and is now being tested by a small group. Expect invitations to be sent out to the list in the near future. * OGSA Information Model - Information Modeling in OGSA - Position Paper https://forge.gridforum.org/projects/ogsa-wg/document/Info_Model_position_p… - BES Information Model https://forge.gridforum.org/projects/ogsa-wg/document/BES_info_model - These are the same versions that were discussed at GGF17. - Fred also requested feedback by email for guideline document. - Andrew has put the table of elements in the BES document (with no rendering). The main issue discussed was the difference between the approach proposed for a (minimal/)general element that can be used to express <name,value> pairs, with the value part being typeless VS extension using an xsd:any and defining a schema. - (See also minutes of GGF17 and April 27.) - There has been experience with both approaches - Difference is relying on explicit typing vs convention; and checking types when validating vs matching time (fail in a subtle fashion) - Discussed whether stronger typing with a schema makes for easier checking. Having an xsd:any doesn't help as much as people might think for checking types; matching might still fail later. - It is still necessary to define conventions. Need to define a set of <name,value> conventions - Andrew's issue is whether the value (in (<name,value>) is typed. - Type checking information is needed somewhere; and wouldn't want to have it only in the code Jay's proposal: 1. minimal; or 2. minimal approach + type checking for base types (e.g., int, float, boolean etc) Agreed to seek the opinions of people who have done work with these approaches on the pros and cons of each approach: - schema/typed: EGEE, Glite - minimal/convention: Condor, LSF ACTION: Jay will contact Platform (Chris Smith) and Condor (Miron Livny) to get feedback on pros / cons of the two rendering approaches ACTION: Darren/Andreas will take the Modeling position paper and discuss it within the JSDL-WG as well * RNS document discussion A revised, simplified, draft was uploaded before GGF17 by Manuel Pereira. It was discussed at GGF17. The purpose of this review was to confirm whether this new draft meets the requirements of other stakeholders and whether it can be submitted to the GGF Editor. There were some comments and requests for clarifications and minor changes but overall it was agreed that this is a good draft and that it meets stakeholders requirements for simplicity and extensibility. Chris Jordan will incorporate the feedback into a new draft, to be ready sometime next week. * OGSA Roadmap document process Jem went through a list of work items (to be uploaded to gridforge) - Main job is updating document set, dependencies and milestones for the document. So a lot of the work is identifying people that will contribute data. - The current infrastructure (excel sheet & pasting) needs a lot of manual work. It works but a better (more automatic) approach might be nice. Hiro thanked all the people volunteering. He explained that the GGF Editor has placed limits on how many names (authors/editors) may appear on the front page. Current rule is not more than three with other people contributing to the work being identified in a separate section. - Dona said she would be happy to contribute to this work in any capacity. - It was agreed that Chris Jordan will replace Jem as the main editor of the Roadmap since he has been involved in OGSA-WG longer than the other volunteers.

1 0

Summer interim F2F meeting survay
by Hiro Kishimoto 22 May '06

22 May '06

Hi all, At this Thursday call, I took an action item to lunch a Zoomerang survey for asking members' availability for Summer F2F meeting. Please take a time to answer questions *ASAP* (at latest May 24 Wednesday): http://www.zoomerang.com/survey.zgi?p=WEB225BX9NE7XS We will review and decide date/location next week. Thanks, -- Hiro Kishimoto Minutes from May 18 call. > Discussed possible dates for summer F2F. > - End of june, before of after HPDC in Europe is one possibility > that was rejected in the past. > - First option: Week of July 17 at Chicago > - Possible for most people on the call > - (Donal cannot make July at all) > - Hiro/Jay to ask Ian Foster and Steve Tuecke whether they can > attend. > - Chosing Chicago in order to get more Globus participation. Chris > Jordan will also ask his Globus contacts if they can > participate. > - Tried to determine a second option in August but there was no > consensus. Many people plan to be on holiday. > > Actions: > - Hiro to do the usual Zoomerang > - Andreas to set up a Google calendar

1 2

GGF17 Resource Management (Information Model) session minutes
by Fred Maciel 20 May '06

20 May '06

Hi, I just uploaded the minutes: https://forge.gridforum.org/projects/ogsa-wg/document/GGF17-OGSA-RM-minu tes/en Regards, 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

[ogsa-wg | Roadmap 1.1 - 1822] gap analysis
by Sourceforge Tracker Monitor 20 May '06

20 May '06

A new artifact has been added: 1822 Submitted by: Hiro Kishimoto Submitted date: 2006-05-20 09:50:39 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=815&aid=1822&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=815&aid=1822&group_id…) Summary: gap analysis Project: Open Grid Services Architecture Tracker: Roadmap 1.1 Artifact ID: 1822 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2006-05-20 09:50:39 Submitted By: Hiro Kishimoto Submit Date: 2006-05-20 09:50:39 Assigned To: Hiro Kishimoto File(s): <None> Description: It is recommended to add "gap analysis" to the roadmap document. For example, each OGSA capability has overview section and lists up major services and documents. If such services or documents are already taken care of any WGs, just refers to corresponding section. If not, this is a "gap" and encourage readers to fulfill such gaps. View the Roadmap 1.1 : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

Naming Document
by Mark Morgan 19 May '06

19 May '06

A new version of the WS-Naming document has been uploaded to grid forge. This document incorporates changes which reflect discussions, both at GGF in Tokyo and on recent Naming telecons, that unify naming with the Web Services Endpoint Identification and Resolution Use Case informational document provided by David Snelling and Frank Siebenlist. Please check the new document out and comment as desired. -Mark

1 0

Teleconference minutes - 18 May 2006
by Andreas Savva 19 May '06

19 May '06

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060518/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 18 May 2006 ================================= * Participants Mike Behrens (R2AD, LLC) Dona Dickinson (Northrop Grumman) Donal Fellows (UoM) Chris Jordan (SDSC) Hiro Kishimoto (Fujitsu) Tom Maguire (EMC) Andreas Savva (Fujitsu) David Snelling (Fujitsu) Ellen Stokes (IBM) Jem Treadwell (HP) Jay Unger (IBM) Minutes: Andreas Savva * April 27 Minutes - approved with no changes * Action item review (Only items with updates are listed below.) - Ellen will do an example of a cluster (e.g., the glue cluster model) and the 'red' to 'blue' mapping for it - Similar example produced as part of GGF17 document produced by Ellen. - (CLOSED) - Hiro and Jun will look at what needs to be provided as a set of common component models and make a proposal to the group. - Hiro and Jun produced some initial material which they presented at GGF. They will continue refining them and will review in future calls. - (CLOSED) - Manuel & Andrew to determine where/when to hold standard hierarchical namespaces discussions. - Chris Jordan gave a status update: A revised draft was produced by GFS-WG before GGF17. It was reviewed at GGF17. - Will give some time to OGSA-Naming-WG and OGSA-Data-WG to review and comment and if agreement is reached to submit to GGF Editor - Agreed to review document on next OGSA call (next Monday) - There is a need to check Andrew's and Manuel's availability - (CLOSED) - Steven Newhouse to ask Jennifer Schopf on the status of the GIN modeling document. - Obsolete. - (CLOSED) * GGF17 review - Postponed minutes approval: the Information Model minutes have not been uploaded yet and many people have not had a chance to read the EMS minutes yet. ** OGSA & Alternative Architectures session - Andreas has asked the panel organizer to upload the slides. One idea is to treat them as public comments to OGSA 1.5. - Clarified that OGSA-WG still has to get separate permission to do so. - It was an interesting panel. It was good to hear the opinions of people not directly involved in OGSA. - Despite the title there was really no discussion of an alternative architecture. It would be interesting to actually talk about alternatives that are not just 'plain web services'. - OGSA also seems to have more potential support within GGF. Dave Snelling will explore this more. * Roadmap 1.1 Jem cannot take on new work at this time though he will continue to be involved in the WG. A call for volunteers for Roadmap editor resulted in three people volunteering to help out. - Agreed to make a final choice next call (Monday) - Once a selection is made there should be a discussion on what needs to be done, how to hand over work, and how to start working on the document. - Agreed on having a separate call between current and next editors to hand over work and assign responsibilites. Jem has a list of things that should be done for the next version and he will share it with the next editor. For example, what is the relation with the GGF live-charter (is design team output properly represented on the live-charter; the live-charter does not have dependencies recorded---too complex; and so on.) Hiro said that a Gap analysis section might be a good addition to the Roadmap document. * OGSA & Glossary 1.5 - Public comment period ended May 9 with no comments. Since then Jem has uploaded some comments from Olegario; and Andreas has put a comment about the 'Alternative Architectures' panel--but still need permission of presenters to use their slides as comments. - Put the Glossary again on next Monday's call, if agenda allows. - Agreed to ask particular people to review and comment: - Ian Foster (Andreas to ask) - Jeff Frey (Jay to ask) - Marvin Theimer (Hiro to ask) * OGSA Security Profiles They are in public comment. There is one comment from Marty Humphrey so far. * Webcast Jem has received feedback and will forward it out to the OGSA list * F2F Planning Discussed using Google Calendar to manage OGSA-WG schedule and planning for F2F. - Andreas will create an OGSA-WG calendar by Monday. Seed it with some known events - Set it up to send calendar invitations to the ogsa-wg list (so needs to have a gmail account) to make it easy for people to register events in the private calendars. - Allow people to subscribe to it (and publish to it). Also support a completely public view not requiring having a google account. Discussed possible dates for summer F2F. - End of june, before of after HPDC in Europe is one possibility that was rejected in the past. - First option: Week of July 17 at Chicago - Possible for most people on the call - (Donal cannot make July at all) - Hiro/Jay to ask Ian Foster and Steve Tuecke whether they can attend. - Chosing Chicago in order to get more Globus participation. Chris Jordan will also ask his Globus contacts if they can participate. - Tried to determine a second option in August but there was no consensus. Many people plan to be on holiday. Actions: - Hiro to do the usual Zoomerang - Andreas to set up a Google calendar * OASIS SDD TC report Hiro reported on the SDD F2F: - The minutes and related materials are available from the SDD TC site (see also Hiro's email on the list). - Identified and discussed overlap with ACS, CDL, and partly with OGSA EMS, JSDL. - SDD TC decided to base their specification on the IBM/Macrovision submission - IUDD V2. And this is a lot different from the GGF specs. - They did agree to converge this spec with the ACS specification. This effort looks like 'low-hanging fruit'. - They are interested in the resource requirements in JSDL and the information model work done in OGSA-WG. - There are considerable problems with CDDLM stemming from different models (e.g., different lifecycle model) - They are interested in some parts of CDL and may borrow ideas but SDD V1 is likely to be very different. - It is a good sign that they are interested in working with us on converging the various specifications. One unclear issue from Hiro's explanation is the extent to which the SDD (IUDD) spec will try to duplicate existing descriptions. (Is it a 'collector' of existing descriptions or does it duplicate and replace existing descriptors?) - Some degree of 'denormalization' (information existing in the native package also appearing in the /canonicalized meta-data description/ in SDD) is not a problem. But if the intention is to replace all existing deployers/installers they are likely to run into a host of other (political) problems. - Since it is unlikely to have a single deployment descriptor there is a need to make sure that kind of thinking is incorporated.

1 0

FW: Evaluation of the Grid webcast
by Treadwell, Jem 18 May '06

18 May '06

Hi, below is the feedback we received from a follow-up survey of webcast participants. The next-to-last question was a "check all that apply" question, so I think the 30 responses really means that the 14 respondents checked a total of 30 boxes. Note that the "future topics" question at the end includes requests for more info from OGSA and from other working groups. - Jem > The session had 138 registrants and 61 classroom attendees. > > Attendees included one or more representatives from the following > businesses and universtities: AAA Computing, ACET Centre University > of Reading, Acxiom, Anydata Limited, Aricie, AT&T, BAE, CA, CERN, > Choreology Ltd, Cisco, commerx, COS, CS a.s.,CUC, DCT, Dell. Deloitte, > Deutscher Wetterdienst, Digital Enterprise Research Institute, Digital > Impact, FGAN, Fujitsu Siemens Computers, FZK, Gatech, Georgia State > University, GGF, GPPD-UFRGS, Gridcore AB, Gridguru, GSI, Hitachi Data > Systems, HPI University of Potsdam, Huawei Tech, IBM, Illinois > Institute of Technology, Imperial, INAF, Iowa State University, KISTI, > KTH, Lemko, Lund University, MAC Holdings (Pvt) Ltd., Mississippi > State University, Nagoya Institute of Technology, National University > of Defense Technology, NCHC, NCR, Network Appliance Inc., NICTA, > Northrop Grumman, NUST Institute of IT, Oak Ridge National Lab, OCL > USA Inc, Oklahoma State University, Oracle, OSU Stillwater, Otago > Polytechnic, Platform Computing, R2AD, Rochester Institute of > Technology, SAS Institute, School of EEE Nanyang Technological > University, SDSC, SGT, SJTU, Softbank BB Corp., Software Perspectives, > Sony Computer Entertainment, Soongsil University, Source Media, Sun > Microsystems Inc., SURA, SURA, Swiss Inst. of Bioinformatics, Synnex > Corp., Tabor Communications, TACC, Telcordia Technologies, The George > Washington University, TNO I&T, TU Delft, TUM, UCSF, University of > Amsterdam, University of Colorado at Denver and Health Sciences > Center, University of Hamburg, University of Michigan, University of > Naples, University of Reading, University of Southampton, Vision > Solutions Inc., Wireless Grids Co., Xyratex, Zhejiang University, Zuse > Institute Berlin. > > The playback is posted at: > http://www.presentationselect.com/HPinvent/archive.asp?eventid=1188 > > Results of the polls were as follows: > > Question Total > Responses Responses Number % of Total > How familiar are you with OGSA? (choose one) 33 Very familiar > 5 15% > Somewhat familiar 10 30% > Limited knowledge 13 39% > No knowledge 5 15% > > What drives your interest in OGSA? (choose one) 32 > Application manager, architect or developer 19 59% > Grid software developer or provider 18 56% > Active member of GGF 8 25% > Member of standards dev't organization other than GGF > 4 12% > Student 5 15% > Press/analyst 0 0% > > > Results of the evaluation were as follows: > > Question Total > Responses Responses Number % of Total > The webcast was very informative 14 Strongly agree 7 > 50% > Agree 6 42.9% > Neutral 1 7.1% > Disagree 0 0.0% > Strongly disagree 0 0.0% > > The webcast provided me with content that I will be able to use in my > work 14 Strongly agree 2 14.3% > Agree 8 57.1% > Neutral 4 28.6% > Disagree 0 0.0% > Strongly disagree 0 0.0% > > Attending the webcast was a valuable use of my time 14 Strongly > agree 5 35.7% > Agree 8 57.1% > Neutral 1 7.1% > Disagree 0 0.0% > Strongly disagree 0 0.0% > > I would recommend the Invent Online series to my colleagues 14 > Strongly agree 6 42.9% > Agree 8 57.1% > Neutral 0 0.0% > Disagree 0 0.0% > Strongly disagree 0 0.0% > > Based either on what you learned in this broadcast or what you already > knew about OGSA: do you think that OGSA technical direction will > establish architecture and specifications that will help your > organization and others to build real grids? (choose one) 14 > Strongly agree 5 35.7% > Somewhat agree 6 42.9% > Neither agree nor disagree 1 7.1% > Somewhat disagree 0 0.0% > Strongly disagree 0 0.0% > Don't know enough 2 14.3% > > Do you think that OGSA effectively blends the technical requirements > and use cases of eScience and eBusiness grids? (choose one) 14 > Strongly agree 3 21.4% > Somewhat agree 6 42.9% > Neither agree nor disagree 3 21.4% > Somewhat disagree 0 0.0 > Strongly disagree 0 0.0% > Don't know enough 2 > > What effects do you think the "open" process that GGF and OGSA follows > has on the definition of architecture and specifications (choose all > that apply 30 Delays or lengthens the process of > standardization too much 0 0.0% > Produces architecture and specifications that do not > provide sufficient detail for realistic implementations 1 > 3.3% > Depends too much on other standards or the work of other > standard bodies 3 10.0% > Produces architecture and specifications that > successfully incorporate the grid community's ideas and requirements > 9 30.0% > Produces specifications that will eventually be adopted > and complied with by most grid software developers 8 26.7% > Produces specifications and architecture that will > promote the interoperability and integration of grid software > components from multiple sources 9 30.0% > > What topics would you like to have discussed in future webcasts > * virtualization survey, comparing technologies single sign-on > security - implications for apps and customers. > * comparison of ETL tools > * More technical information on OGSA. > * Grid Computing Scientific/Business Workflow systems] > * Interview of the following GGF workgroups : -DAIS-WG; -DFDL-WG; > > >

1 0

Refactored RNS Specification - Post GG17 Discussion
by Christopher Jordan 18 May '06

18 May '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is the most recent version of the refactored RNS hierarchical namespace document. Please read it if you get a chance so that we can discuss it at the next OGSA call. Begin forwarded message: > From: Manuel Pereira <mpereira(a)almaden.ibm.com> > Date: May 11, 2006 11:58:56 AM PDT > To: gfs-wg(a)ggf.org > Cc: ogsa-naming-wg(a)ggf.org > Subject: [gfs-wg] Refactored RNS Specification - Post GG17 Discussion > > > Hello all, > > This note is intended to inform you that the most recent revision > of the "refactored" RNS specification document is now available on > GridForge: > https://forge.gridforum.org/projects/gfs-wg/document/ > Resource_Namespace_Service_Refactored/en/4 > > This revision incorporates the very minor adjustments discussed > during the GFS-WG session in Tokyo. > > Best regards, > Manuel Pereira > ------------------------------------------------------ > IBM Almaden Research Center > 1-408-927-1935 [Tieline: 457] > mpereira(a)us.ibm.com > ------------------------------------------------------ - ---------------------------------------------------- Chris Jordan HPC Systems Engineer High End Computing Systems Group San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEbHs5PCVtcXn6kg8RAlf4AJ9+dnkDS8sGNeQpYwIb7Lhgh6+7DwCbBwXN NDRm7trP2eh5jpeMGGEuowM= =8JqJ -----END PGP SIGNATURE-----

1 0

OASIS Solution Deployment Descriptor TC
by Hiro Kishimoto 18 May '06

18 May '06

Hi all, OASIS OASIS Solution Deployment Descriptor TC is developing XML schema for deployment related metadata of multiple software packages (they call solution). Their scope is widely overlapped with CDDLM, ACS, JSDL, and OGSA-EMS. In order to prevent from undesirable divergence, Keisuke Fukui (ACS-WG co-chair) and I have attended to SDD TC F2F meeting this week, introduced our CDDLM/ACS/JSDL specs and ask them to utilize these GGF specifications if appropriate. http://www.oasis-open.org/committees/download.php/18091/ggf-sdd-submission.… http://www.oasis-open.org/committees/download.php/18167/GGF-spec-submission… The F2F meeting went very well and SDD TC agreed that although they chose IUDD V2 specification as their base specification, they will align and converge with ACS/JSDL/CDDLM specs in long team and also short term. It is very good news for both GGF and OASIS. http://www.oasis-open.org/committees/download.php/18210/SDDF2F.html http://www.oasis-open.org/committees/download.php/18208/Strategy%20for%20De… http://www.oasis-open.org/committees/download.php/18209/Deployment%20Descri… If time permits, I will report out and answer questions on this new thrilling opportunity at Thursday's OGSA-WG weekly call. Thanks, -- Hiro Kishimoto

1 0

CFP GridNets 2006 : Extended Deadline
by Antoine.Pichot＠alcatel.fr 17 May '06

17 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 ** Extended Deadline ** : June 7, 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 chairs: Wayne Clark (Cisco), Yufeng Xin (MCNC) 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 Accelerator 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

Proposed agenda for May 18 call
by Hiro Kishimoto 16 May '06

16 May '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on May 18th Thursday from 8:30am - 10:30am (CDT). Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0518 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (April 27) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060427/en/1 Action Items status review (see the bottom of this email) Agenda bashing 2) GGF17 review (20 min) OGSA sessions minutes approval Any comments on GGF17 3) OGSA roadmap document authorship (20 min) We need new co-editors for roadmap document Discuss how to take it over from Jem 4) OGSA 1.5 Architecture and glossary public comments (20 min) We need to solicit more comments for Arch doc and glossary. 5) OGSA-WG and the fellow WGs August F2F meeting plan (20 min) As we discussed at the GGF17 in Tokyo, Andreas will set up gCalendar and let you know the process for pick F2F date. 6) Wrap up (10 min) AOB <*NEXT CALL*> May 22 (Mon): OGSA Information Model (Ellen and Fred), Telecon schedule in the future May 25 (Thu): OGSA EMS architecture scenarios (Steven), OGSA authorization call-out proposal review (Frank) <*ACTION ITEMS*> From April 27 call - Ellen will do an example of a cluster (e.g., the glue cluster model) and the 'red' to 'blue' mapping for it From April 24 call - Frank to write up and send to the list a one page summary of the authorization call-out proposal. From April 6 F2F meeting - Hiro and Jun will look at what needs to be provided as a set of common component models and make a proposal to the group. From April 5 F2F meeting - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. - Manuel & Andrew to determine where/when to hold standard hierarchical namespaces discussions. From April 4 F2F meeting - Steven Newhouse to ask Jennifer Schopf on the status of the GIN modeling document. Deferred - Jay check and find out relatively small funding to Globus to develop document on their security work (April 6 F2F) - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (April 4 F2F) -- Hiro Kishimoto

1 0

OGSA Roadmap editor
by Treadwell, Jem 15 May '06

15 May '06

Hi, It's now 9 months since we published the OGSA Roadmap v1.0, and we need to begin work on the next version. However, because of other commitments I won't be able to serve as co-editor for this version. If anyone would like to volunteer for this role, would you please let me and Hiro know? Thanks! - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com>

1 0

No monday call on May 15th
by Hiro Kishimoto 15 May '06

15 May '06

Hi all, Thank you very much for all of you who came to GGF17 in Tokyo. We have had very lively and productive sessions. Following our tradition, we won't have conf call on May 15th. Our next call will be this Thursday, May 18th. Thanks again, -- Hiro Kishimoto

1 0

Thoughts on extensions mechanisms for the HPC profile work
by Marvin Theimer 12 May '06

12 May '06

Hi; This email is intended to describe my views of the set of extension mechanisms that are both necessary and sufficient to implement the common cases that we have identified for the HPC profile work (see the document "HPC Use Cases - Base Case and Common Cases", a preliminary draft of which I sent out to the ogsa-wg mailing list several weeks ago). These views are in large part derived from ongoing discussions that Chris Smith and I have been having about the subject of interoperable job scheduling designs. This email is intended to start a discussion about extension mechanisms rather than define the "answer" to this topic. So please do reply with suggestions for any changes and extensions (:-)) you feel are needed. Marvin. Additive vs. modifying extensions At a high level, there are two types of extensions that one might consider: * Purely additive extensions. * Extensions that modify the semantics of the underlying base-level design. Purely additive extensions that, for example, add strictly new functionality to an interface or that define additional resource types that clients and schedulers can refer to, seem fairly straight-forward to support. Modifying extensions fall into two categories: * Base case semantics remain unchanged to parties operating at the base (i.e. un-extended) level. * Base case semantics change for parties operating at the base level. Modifying extensions that leave the base-level semantics unchanged are straight-forward to incorporate. An example is adding at-most once semantics to interface requests. These operations now have more tightly defined failure semantics, but their functional semantics remain unchanged and base-level clients can safely ignore the extended semantics. Extensions that change base-level semantics should be disallowed since they violate the fundamental premise of base-level interoperability. An example of such an extension would be having the creation of jobs at a particular (extended) scheduler require that the client issue an additional explicit resource deallocation request once a job has terminated. Base-level clients would not know to do this and the result would be an incorrectly functioning system. Types of extensions I believe the following types of extensions are both necessary and sufficient to meet the needs of the HPC profile work: * Addition of new WSDL operations. * This is needed to support additional new functionality, such as the addition of suspend/resume operations. As long as base-level semantics aren't modified, this form of extension seems to be straight-forward. * Addition of additional parameters to existing WSDL operations. * As long as base-level semantics are maintained, this form of extension is also straight-forward. An example is adding a notification callback parameter to job creation requests. However, it is not clear whether all tooling can readily handle this form of "operation overloading". It may be better - from a pragmatic point-of-view - to define new WSDL operations (with appropriately defined names) that achieve the same effect. * 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. * Extensions to state diagrams. * Chris Smith is in the process of writing up this topic. * Standardized extensions to things like resource definitions and other declarative definitions (e.g. about provisioning). * The base use case assumes a small, fixed set of "standard" resources and other concepts (e.g. working directory) that may be described/requested. The simplest extension approach is to define additional specific "standard sets" that clients and services can refer to by their global name (e.g. the posix resource description set or the Windows resource description set) and of which they pick exactly one to use for any given interaction. * The problem with this simplest form of extension is that it provides only a very crude form of extensibility with no notion of composition or incremental extension of existing definition sets. This is sufficient for very course-grained characterizations, such as "Windows environment" versus "Posix environment", but not for finer-grained resource extensions. An alternative is to define composable sets that cover specific "subjects" (e.g. GPUs). In the extreme, these sets could be of size 1. This implies that clients and services need to be able to deal with the power set of all possible meaningful combinations of these sets. As long as individual definitions are independent of each other (i.e. the semantics of specifying A is unchanged by specifying B in the same description) this isn't a big problem. Allowing the presence of different items in a description to affect each other's semantics is arguably a variation on modifying the base-level semantics of a design via some extension to the design and hence should be disallowed. * If resource descriptions are used only for "matchmaking" against other resource descriptions then another approach is to allow arbitrary resource types whose semantics are not understood by the HPC infrastructure, which deals with them only as abstract entities whose names can be compared textually and whose associated values can be compared textually or numerically depending on their data type. It is important to understand that, whereas the "mechanical" aspects of an HPC infrastructure can mostly be built without having to know the semantics of these abstract resource types, their semantics must still be standardized and well-known at the level of the human beings using and programming the system. Both the descriptions of available computational resources and of client requests for reserving and using such resources must be specified in a manner that will cause the underlying HPC "matchmaking" infrastructure to do the right thing. This matchmaking approach is exemplified by systems such Condor's class ads system. * It should be noted that a generalized matchmaking system is not a trivial thing to implement efficiently and hence one can reasonably imagine extensions based on any of the above approaches to extending resource (and other) definitions. * Hierarchical and extended representations of information. * XML infosets provide a very convenient way to represent extended descriptions of a particular piece of information. * Another form of hierarchical information display shows up when multi-level scheduling systems are involved. In this case it may be desirable to represent information either in a form that hides the scheduling hierarchy or in a form that reflects it. Consider how to represent the list of compute nodes for a job running across multiple clusters: A flat view might list all compute nodes in an undifferentiated list. A hierarchical view might provide a list of clusters, each of which describes information about a cluster, including a list of the compute nodes in that cluster that the job is running on. Both views have their uses. XML infosets are convenient for encoding the syntax of either view, but an extension supporting information representation in these sorts of systems will also have to define the semantics of all allowed hierarchies. * Decomposition of functionality into "micro" protocols. * Micro protocols should reflect things that must occur at different times (e.g. resource reservation/allocation vs. resource use/job-execution) or that can be employed in a stand-alone manner (e.g. job execution vs. data transfer). The decomposition that seems relevant for the HPC use cases (i.e. are visible to clients) is the following: * The base case involves interaction between a client and a scheduler for purposes of executing a job. * A client may wish to independently reserve, or pre-allocate resources for later and/or guaranteed use. Note that this is different from simply submitting a job for execution to a scheduler that then queues the job for later execution - perhaps at a specific time requested by the client. For example, a meta-scheduler might wish to reserve resources so that it can make informed scheduling decisions about which "subsidiary" scheduler to send various jobs to. Similarly, a client might wish to reserve resources so as to run two separate jobs in succession to each other, with one job writing output to a scratch storage system and the second job reading that output as its input without having to worry that the data might have vanished during the interval that occurs between the execution of the two jobs. * A client may wish to query a scheduler to learn what resources might be available to it, without actually laying claim to any resources as part of the query (let alone execute anything using those resources). Scheduling candidate set generators or matchmaking services such as Condor would want this functionality. * A client may need to transfer specific data objects (e.g. files) to and from a system that is under the control of a job scheduling service. * Micro protocols may have relationships to each other. For example, job execution will need to be able to accept a handle of some sort to resources that have already been allocated to the requesting client.

5 13

materials for OGSA Info Model session (GGF17) - Friday May 12 @ 1345
by Ellen Stokes 11 May '06

11 May '06

Here are the materials for the OGSA Info Model session today at GGF. They are also posted on OGSA gridForge site under GGF17 directory. Ellen

1 0

CFP - AGNM 2006
by Masum Hasan (masum) 10 May '06

10 May '06

Call for Papers ================= AGNM 2006 Second IEEE/IFIP International Workshop on Autonomic Grid Networking and Management October 26th-27th, 2006, Herbert Park Hotel, Dublin, Ireland Held as part of the IEEE/IFIP 2nd International Week on Management of Networks and Services Website: http://www.manweek2006.org/agnm/agnm.php Autonomic Grid Computing (AGC) deals with self-managing and self-adapting parallel and distributed computing and associated data management on a distributed and parallel Grid of computational machines (PCs, servers, supercomputers, clusters) and storage systems. Grid computing is performed with the support of two major infrastructure components: 1) a Grid middleware, such as Globus or UNICORE, which provides advanced services and supports Grid resource management, and 2) a fabric layer, which comprises the underlying systems, such as computers, operating systems, and storage systems. A fabric layer component of particular importance is the network since all distributed services rely on the capabilities of the interconnecting network. Recently, the Grid Community has started efforts to enhance the core services of a Grid middleware with autonomic capabilities so that the functions are self-managing. For example, an autonomic Grid resource allocation manager, instead of statically allocating or releasing resources to Grid applications, could do so adaptively, or self-heal to failures. However, the AGC and associated infrastructure (AGCI) is geared mainly towards computational (servers, supercomputers) and storage resources. In other words, the autonomic behavior of AGC and AGCI is a function of changes in computational and storage resources, but not networking resources. Hence there is need for support of Autonomic Grid Networks (AGN) that incorporates into the Grid the following: 1) Network resources distributed across LAN, MAN and WAN, 2) Autonomic and on-demand functions (into various layers and components, such as a Grid middleware). The autonomic functions may be conceptually similar to the ones provided in the lower layer (Layers 3, 2, 1) networks, such as self-control (dynamic rerouting, such as IGP rerouting), self-protection ([G]MPLS Fast Rerouting and Protection, Sonet/SDH protection switching), and self-healing (control and data plane high-availability, etc.). For example, in a typical Grid, the resource management architecture is client-server oriented, where resources are typically registered to and pulled from a particular service. In contrast, in an AGN, the resource management architecture could be distributed and autonomous, where resource requests are routed by autonomous and distributed AGN middleware components. This one-day workshop offers a unique opportunity for researchers and practitioners to exchange ideas and experiences on problems, challenges, solutions and potential future research and development issues in this new field of Autonomic Grid Networking and Management. In addition to paper presentations, the workshop provides an intimate setting for discussion and debate through panels and group work. The authors are encouraged to submit original papers on topics related to the concepts described above, including, but not limited to: - Grid middleware enhancements for AGN - Cluster middleware enhancements for AGN - Network-aware autonomic Grid scheduling - Network-aware autonomic Grid data and storage management - Network-aware autonomic cluster scheduling and management - AGN specific resource discovery - AGN QoS (combined application and abstracted network QoS) management - AGN routing - AGN self-healing and self-protection - AGN high-availability - AGN monitoring and performance management - AGN effects on HPC applications - HPC applications (MPI and other) on AGN - HPC applications (MPI and other) on MAN and WAN AGN - Commercial applications (CRM, ERP, Financial, etc.) on AGN - P2P AGN Submission ---------- For online submission instructions please visit http://www.manweek2006.org/agnm/submission.php Questions should be directed to agnm06(a)anut.fh-aachen.de IMPORTANT DEADLINES ------------------- Submission: May 19 2006 Notification: July 7 2006 Camera ready: August 2 2006 Workshop: October 26-27 2006 Organizing Committee: --------------------- Workshop Chair: Masum Z. Hasan (Cisco Systems, USA) Workshop TPC Co-chairs: Volker Sander (University of Aachen, Germany) and Silvia Figueira (Santa Clara University, USA) Technical Programme Committee ----------------------------- Lina Battestilli, MCNC, USA Raouf Boutaba, U Waterloo, Canada Rob Brennan, Ericsson R&D, Ireland Wayne Clark, Cisco Systems, USA Asit Dan, IBM Watson Research C, USA Cees DeLaat, U Amsterdam, Netherlands Gabi Dreo-Rodosek, LRZ, Germany Horst Dumcke, Cisco Systems, France Tiziana Ferrari, INFN, Italy Markus Fidler, U Toronto, Canada Silvia Figueira, SCU, USA Wolfgang Gentzsch, MCNC, USA Rüdiger Geib, T-Systems, Germany Masum Z. Hasan, Cisco Systems, USA Michiaki Hayashi, KDDI, Japan Doan B. Hoang, U Sydney, Australia Admela Jukan, UIUC, USA Gigi Karmous-Edwards, MCNC, USA Francis Lee, NTU, Singapore Edgar Magaña, UPC, Spain J.P. Martin-Flatin, UQAM, Canada Manish Parashar, Rutgers U, USA Gerard Parr, University of Ulster, UK Pascale Primet, INRIA, France Volker Sander, U Aachen, Germany Dimitra Simeonidou, U Essex, UK John Strassner, Motorola Lab, USA Franco Travostino, Nortel Networks, USA Michael Welzl, U Innsbruck, Austria Peter Tomsu, Cisco Systems, Autria Yufeng Xin, MCNC, USA --Masum http://www.cs.toronto.edu/~zmhasan/ <http://www.cs.toronto.edu/~zmhasan/>

1 0

Straw man design proposal for HPC profile
by Marvin Theimer 08 May '06

08 May '06

Hi; The virtual design effort around the HPC Profile initiative has created a use case document, has discussed extension mechanisms, and has received a straw man design proposal from Ian Foster and Dave Snelling. Chris Smith and I have put together a second straw man design proposal so that we have two different proposals to discuss at the HPC Profile BoF in Tokyo next week. That proposal is included as an attachment to this email. Whereas Ian and Dave's ESI design had as its primary focus a unification of the Globus and Unicore designs, the focus of Chris and my design proposal is an evolutionary design in which there is a base case and numerous optional extensions. Of course, it also represents our views on how we think the HPC profile should look. :-) The enclosed paper is intentionally an unfinished design since our goal is to engender discussion and obtain feedback from the grid community for the HPC Profile effort. So we invite comments and feedback, both in email to this mailing list and in person during the BoF next week in Tokyo. Thanks, Marvin (and Chris).

1 0

RE: [cddlm] Basic POSIX Component & template draft
by Dave Berry 08 May '06

08 May '06

Hi, It sounds like you're having interesting discussions. What concerns me is how does this work relate to: - the hierarchical naming level of the OGSA naming system? - the work of the Grid File System working group? - ByteIO? - the OGSA Data Architecture? Dave. > -----Original Message----- > From: owner-cddlm-wg(a)ggf.org [mailto:owner-cddlm-wg@ggf.org] > On Behalf Of Hiro Kishimoto > Sent: 08 May 2006 14:56 > To: Steve Loughran > Cc: OGSA WG; cddlm-wg(a)ggf.org > Subject: Re: [cddlm] Basic POSIX Component & template draft > > Hi Steve, > > Your file & filesystem components are very good. They are > what I am looking for. One more question I have in my mind is > how to set user-id, group-id, and permissions to deployed files. > > Can you call in OGSA-EMS session on Wednesday? > It starts 5:45pm JST = 9:45am UK. > > The dial-in number for this session; > US: +1 718 3541071 (New York) or > +1 408 9616509 (San Jose) > UK: +44 (0)207 3655269 (London) > Japan: +81 (0)3 3570 8225 (Tokyo) > PIN: 4371991 > > Thanks, > ---- > Hiro Kishimoto > > Steve Loughran wrote: > > Hiro Kishimoto wrote: > >> Hi all, > >> > >> Jun Tatemura and I took a home work assignment about "Basic POSIX > >> Component" for BLAST application deployment. > >> > >> Attached is my first-cut draft and hope to discuss at > GGF17 OGSA EMS > >> session. > >> Please have a look and give your feedbacks before or at the GGF17. > >> Your feedbacks are very important. > >> > >> Thanks and see you in Tokyo! > > > > > > This is really good, and I do agree, we do need a set of > foundational > > things to deploy. > > > > One thing I would argue, having learned the lessons of both Ant and > > SmartFrog, is that a consistent model of file system > components comes > > first. That is, we need components to model > > > > -files (with a liveness test that verifies the file is > present) -paths > > (an ordered list of files/directories) -directories (with > components > > that can create a dir on deployment, optionally to delete > it and its > > contents on termination) -wildcarded sets of files (**/*.csv) > > -temporary files and directories -cached downloads -text files > > > > I'm attaching the PDF file describing the current smartfrog set of > > components that do this. The underlying way that this is > done is that > > all components that consider themselves to be sources of > > filenames/paths set the attribute absolutePath at runtime. They > > usually also export an RMI interface for RPC-style > operations, along side their RESTy state. > > > > A standard set of filesystem components lets you include the > > operations to create and clean up directories, temporary files and > > other housekeeping operations into the workflows of a deployment. > > > > Looking at the Posix proposal, I'd suggest starting with > the reusable > > set of filesystem types, including a <fs:mount> component > that could > > mount a local or remote filesystem, and which would then pass the > > local location to interested parties as the > filesystem:absolutePath attribute. > > > > You absolutely don't need to introduce a new shared datatype > > FileSystemName, because that implies some kind of alternate > > naming/locating scheme outside of what CDL and the runtime > has built in. > > Dynamic CDL references are sufficient to crosslink > information inside > > the graph of deployed things, and offer flexibility as well > as ease of > > management (you see them when you walk the graph). > > > > First, we'd need filesystem types: > > > > <tmp cdl:extends="fs:TempFileSystem"> > > <fs:Description> ... </fs:Description> > > <fs:DiskSpace> > > <fs:LowerBoundedRange>10737418240.0</fs:LowerBoundedRange> > > </fs:DiskSpace> > > </tmp> > > > > <home cdl:extends="fs:Directory"> > > <fs:Description>Chris's home directory</fs:Description> > > <fs:dir>/home/csmith</fs:dir> > > </home> > > > > When deployed, both of these would add absolutePath as an > attribute, > > so that tmp/absolutePath woudl resolve to, say, tmp/work01234/ and > > home:absolutePath to /home/csmith. > > > > > > You'd then mount a blast dir, say on an nfs filesys whose URL you > > provide > > > > <blastfs cdl:extends="fs:RemoteFileSystem"> > > <fs:url>nfs://filestore/csmith/blast</fs:url> > > <fs:mountUser>csmith</fs:mountUser> > > </tmp> > > > > The database file is under here, and you declare that it > must exist. > > Deployment will fail > > if it is absent: > > > > <db cdl:extends="fs:File"> > > <fs:dir cdl:ref="/tmp/absolutePath" cdl:lazy="true" /> > > <fs:filename>db/ncbiblast/est</fs:filename> > > <fs:filemustexist>true</fs:filemustexist> > > </db> > > > > > > To use it, just refer to its path > > > > <blast:database cdl:ref="/db/absolutePath" cdl:lazy="true"/> > > > > Paths could be represented by some list-like element, whose entries > > are evaluated at deploy time and then a platform-specific > path created > > as a result > > > > <path cdl:extends="fs:Path"> > > <pathentry cdl:ref="/blastfs/absolutePath" cdl:lazy="true" /> > > <pathentry cdl:ref="/home/absolutePath" cdl:lazy="true"/> </path> > > > > On Windows /path/absolutePath would become something like > > "\\filestore\csmith\blast;c:\documents and settings\csmith" > > while on unix it could be > > "/nfs/filestore/csmith/blast:/home/csmith" > > > > This information now goes down to the jsdl component > > > > <jsdl-posix:Environment name="PATH" > > cdl:ref="path:absolutePath" cdl:lazy="true"/> > > <jsdl-posix:Environment name="TMPDIR" > > cdl:ref="tmp/absolutePath" cdl:lazy="true"/> > > > > > > -Steve > > > > > > > > > > > > > > > >

2 1

Basic POSIX Component & template draft
by Hiro Kishimoto 08 May '06

08 May '06

Hi all, Jun Tatemura and I took a home work assignment about "Basic POSIX Component" for BLAST application deployment. Attached is my first-cut draft and hope to discuss at GGF17 OGSA EMS session. Please have a look and give your feedbacks before or at the GGF17. Your feedbacks are very important. Thanks and see you in Tokyo! -- Hiro Kishimoto

2 3

RE: [ogsa-wg] Initial draft of HPC profile working group charter
by Dave Berry 07 May '06

07 May '06

Hi, All the discussion I've seen about this profile so far has focussed on specifying and submitting jobs, but the proposed charter says that this is only one of two areas of interest; the other being data staging. The immediate question is what link will this profile work have to the Data Movement Interface Specification group? Will the profile refer to the DMIS spec in the same way that it will refer to JSDL and BES? (Of course, JSDL also covers data staging to some extent). Work is also continuing on the data aspects of the OGSA architecture, in the OGSA Data WG. I would encourage the HPC profile group to engage with the OGSA Data group and the DMIS group concerning how to fit data staging into the overall architecture. Unfortunately I won't be in Tokyo next week but it would be useful if members of these groups could get together there to agree a working relationship. Best wishes, Dave. _____ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marvin Theimer Sent: 05 May 2006 01:48 To: ogsa-wg(a)ggf.org Subject: [ogsa-wg] Initial draft of HPC profile working group charter Hi; Enclosed is an initial draft of the OGSA HPC profile working group charter. This will be brought up for discussion at the HPC profile BoF at the upcoming GGF17 conferenece in Tokyo. In the mean time, please feel free to comment on the draft via email to this mailing list. Thanks, Marvin.

3 3

Initial draft of HPC profile working group charter
by Marvin Theimer 07 May '06

07 May '06

Hi; Enclosed is an initial draft of the OGSA HPC profile working group charter. This will be brought up for discussion at the HPC profile BoF at the upcoming GGF17 conferenece in Tokyo. In the mean time, please feel free to comment on the draft via email to this mailing list. Thanks, Marvin.

2 2

Straw man design proposal for HPC profile
by Marvin Theimer 06 May '06

06 May '06

Hi; The virtual design effort around the HPC Profile initiative has created a use case document, has discussed extension mechanisms, and has received a straw man design proposal from Ian Foster and Dave Snelling. Chris Smith and I have put together a second straw man design proposal so that we have two different proposals to discuss at the HPC Profile BoF in Tokyo next week. That proposal is included as an attachment to this email. Whereas Ian and Dave's ESI design had as its primary focus a unification of the Globus and Unicore designs, the focus of Chris and my design proposal is an evolutionary design in which there is a base case and numerous optional extensions. Of course, it also represents our views on how we think the HPC profile should look. :-) The enclosed paper is intentionally an unfinished design since our goal is to engender discussion and obtain feedback from the grid community for the HPC Profile effort. So we invite comments and feedback, both in email to this mailing list and in person during the BoF next week in Tokyo. Thanks, Marvin (and Chris).

1 0

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

Teleconference minutes - 27 April 2006
by Andreas Savva 01 May '06

01 May '06

Attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060427/en/1 See you at GGF17. -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 27 April 2006 =================================== * Participants Jay Unger (IBM) Jem Treadwell (HP) Ellen Stokes (IBM) Dave Snelling (Fujitsu) Andreas Savva (Fujitsu) Joel Replogle (GGF) Steven Newhouse (OMII) Mark Morgan (UVa) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Minutes: Andreas Savva * Summary of new actions ACTION: Ellen will do an example of a cluster (e.g., the glue cluster model) and the 'red' to 'blue' mapping for it ACTION: Hiro/Dave S/Jay/Ellen/... to talk offline and make a proposal for a summer meeting location and time, possibly in mid-July. * April 24 minutes (draft 2) approved with no changes * Webcast recap Webcast went well and a recording will be posted in due course. There were some dial-in issues and these may explain why there was no voice Q&A. A number of questions were submitted through the online system. A good percentage of registered people turned up and Jem's impression is that most were new to OGSA. Jay mentioned that sometimes people register just so that they can get an update email later for the recording. One idea is not to state in advance that a recording will be available later. Also people may not eventually turn up due to the inconvenient time slot. Doing webcasts in two parts may help against the inconvenient time slot problem. For example, do just the explanation and post the recording. And then arrange for multiple Q&A sessions at different times convenient to different time zones. The group produced a good slide deck and it is expected that it can be used for other occasions. For example, Hiro is planning his keynote off this deck. Mark Linesch also attended. Thanks to all who took part and especially to Jem for pulling everything together despite the tight schedule. * Action review [Only updated actions shown here.] - Steven Newhouse to ask Jennifer Schopf on the status of the GIN modeling document. There is no such document; delete action. (Done) - Ellen will do a revised visio diagram that has only the relevant BES attributes and JSDL attributes (base it off the info_model_for_BES/BES Container class) It is today's agenda. File (pdf) has been uploaded. - Hiro asked Ellen to also upload the Visio file to gridforge. - Andreas will sent information to Ellen on how to attach a file (e.g., visio) to a pdf file to simplify uploading to gridforge. (Done) - Andreas: to finalize OGSA WSRF BP 1.0 doc and make a final call - An updated draft is available and should be made public within a few days. * GGF17 session review ** Keynote - Hiro is planning to base his keynote on the webcast material after removing basic stuff and merging some slides into transitions. ** Information model - Discuss capabilities and requirements and their relation, including position papers. ** EMS session - Andreas has confirmed that NAREGI (beta) is not using WS-Agreement. - Steven N will produce a new version of the Scenarios document by GGF17. ** Session scheduling - Steven Newhouse has conflicts with both OGSA sessions. The group discussed re-scheduling options, including swapping times with other groups. - One session (EMS) was moved to Wednesday at 5:45 and the other (Information Model) to Friday at 1:45. There is now a conflict with RSS-WG and Joel will offer them one of the vacated OGSA slots on Thursday. ** OGSA F2F update Discussed options for OGSA F2F during the summer. Previously the group had agreed on two meetings: end of June and end of August. In this call there was no consensus for two meetings during the summer. Instead it was agreed to have a single meeting mid-July. ACTION: Hiro/Dave S/Jay/Ellen/... to talk offline and make a proposal for a summer meeting location and time, possibly in mid-July. * Information model discussion Using the material sent out by Ellen. https://forge.gridforum.org/docman2/ViewProperties.php?group_id=42&category… ** Slide 2 The abstract model (in blue) is intended to be much simpler than the instance model (red). It is a list of capabilities of the container, probably described as <name, value> pairs. For example: <name = operatingsystem, value = redhat> and so on There was agremeent that it is desirable for resource capabilities (blue) and activity requirements (green) to have the same language (symmetrical rendering) and that the simple model (blue) should be generated and updated (automatically by algorithms) from the detailed model (red). The main unresolved difference is whether extensibility should be done using xml extensibility (as envisaged by JSDL) or by defining some xml (typeless) element that can express 'something' as a capability. One example to highlight this difference is <OperatingSystem> RedHat </OperatingSystem> versus <capability name=OperatingSystem value=RedHat> It was agreed to table the rendering issue for now. ** Slide 3 - The concrete CIM 'stuff' gets mapped into the 'aggregated' BES abstract stuff - Note the duality of jsdl 'execution requirements': as both job requirements and container capabilities. ** Slide 4 ACTION: Ellen will do an example of a cluster (e.g., the glue cluster model) and the 'red' to 'blue' mapping for it

1 0

FINAL CALL: OGSA WSRF BP 1.0 (draft 46)
by Andreas Savva 01 May '06

01 May '06

This is a final call for re-submitting a revised version of the OGSA WSRF BP 1.0 to the GGF Editor. Please review draft 46 (changes accepted) or draft 45 (change-tracked version) and send your comments to the list until the end of business Friday, May 5. Background: You may recall that the WSRF BP 1.0 finished its public comment last December. A revised version was ready in January but it was agreed to wait for the publication of OASIS Standard versions of the WSRF specifications. This version uses the OASIS Standard WSRF specifications; and was also updated to make the other referenced specifications consistent (e.g., use the same version of WS-Addressing). Draft 46: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-wsrf-b… or http://tinyurl.com/lxfkz Draft 45: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-wsrf-b… or http://tinyurl.com/kf7r5 Thanks to all who reviewed versions leading up to this one and especially to Vivian Li for checking the referenced specifications. -- Andreas Savva Fujitsu Laboratories Ltd

1 0

No call on May 1, 4, and 8
by Hiro Kishimoto 29 Apr '06

29 Apr '06

Hi all, Since the week of May 1st is Japanese holidays (Golden Week), OGSA-WG will have no calls. Also many of you are going to travel on May 8th, we don't have a call either. Have a great weekend! Thanks, -- Hiro Kishimoto

1 0

[Fwd: [ogsa-naming-wg] Minutes and next meeting]
by Frank Siebenlist 28 Apr '06

28 Apr '06

FYI - Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

More comments: HPC Use Cases -- Base Case and Common Cases
by Balle, Susanne 28 Apr '06

28 Apr '06

Marvin, Enclosed find the remaining of my comments: Page 5. (top paragraph) I think I know what you mean by "with the ambiguity of distinguishing between scheduler crashes and network partitions ". "scheduler crashes" is obvious. I am assuming that by "network partitions" you are inferring that various sub-networks are going to have different response time which will have an effect on the time it takes to deliver a call-back message. Reading further along in the same paragraph I am now not sure I know what you mean by "network partitions". Page 5. Section 3.3 The topic of this section is clear (described in the first line of the paragraph) but of the section is a little confusing. "possibility that a client cannot directly tell whether its job submission request has been successful ..." --> Do we expect the client to re-submit the job if the submission failed or do we expect users to inspect that their job has in fact been submitted and resubmit if needed? I am wondering if we assume the later if that wouldn't result in users re-launching their jobs several time if they do not see their job listed in some state when pulling the job scheduler for the state of their job? I guess I do not understand why so much emphasis is put on the "At-Most-Once" or "Exactly-Once". Can't the client poll the Job scheduler and ask the JS for a list of jobs queued, running, terminated, failed, etc.? It might be useful for the client to be able to submit jobs with a special keyword like JOB_SUBMITTED_BY since that would reduce the list it gets back. It would be nice if the value for the keyword was a unique identifier but doesn't have to be. Most schedulers allows you to name or associate a group to programs so that feature could be used as special keyword. Page 6. Section 3.4 General question: Are you taking into account that user applications will require different software? 1. For example if my executable is compiled for Linux, Intel platform then I would like to run it on a Linux,Intel system and not a Linux,AMD system. 2. Are you assuming that the program will be compiled on the fly on the allocated system? or pre-compiled and then staged? I agree that staging the data is going to be an interesting topic. All this is probably out-of-band for the HPC JS Profile but should be considered somewhere. I am sure it is I just don't know where. I like the section on virtual machines and think that they will be used more and more in the future. Page 7. Extended Resource Features The second approach (arbitrary resource types ...) is the only one that make sense to me since that approach is extensible. I believe that Moab is implementing this approach as well. Page 8. Extended Client/System Administrator Operations Are you assuming that System Administrators will be able to perform sys admin operations on somebody else's system? I don't think that is right. You mention suspend-resume. Are you thinking of suspending a job running across several clusters that are in different organizations? Or just suspending a job on a single cluster/server? Again I am trying to figure out how this fit in with "One important aspect, is that the individual clusters should remain under the control of their local system administrator and/or of their local policies". I believe that suspend-resume is a JS operation or an operation to be performed by the local sys admin, NOT by remote sys admins. If we are now talking about a meta-scheduler then yes it makes sense. In the case of a meta-scheduler it might take over the individual JS and schedule jobs base on its own policies, on its job reservation system, etc. In this case I look at it as we have one deciding entity (the meta-scheduler) and several "slaves". Moab and Maui are the only meta-scheduler I an familiar with and they do take over the scheduling decisions/node allocations/etc and just submit jobs to the local job schedulers. This does of course assume that the local system administrators have agreed on a schedule when their cluster is shared within this greater infrastructure. This is a different approach than having jobs passed onto their local scheduler and run on their systems. This just seems to be a different approach from the one that is taken in this paper. I might be wrong. If I am please educate me. Page 9. Section 3.10 Don't forget UPC (Unified Parallel C: http://upc.nersc.gov/) This parallel programming paradigm is getting more and more interest from several communities. We'll need to provide support for UPC as well. Page 10. Section 3.13 A meta-scheduler approach that make sense to me is to allow developers to submit their job to their local cluster using their "favorite" scheduler commands and then have the meta-scheduler load-balance the work and forward the job to another system/cluster if needed. Moab from cluster resources support this approach even if the clusters have different JSs. They have a list of supported JS such as LSF, PBSpro, SLURM, etc. and they can "translate" one JS's commands into another within that supported set. Page 11. SLURM is missing. Let me know what you think, Regards Susanne --------------------------------------------------------------- Susanne M. Balle, Hewlett-Packard High Performance Computing R&D Organization 110 Spit Brook Road Nashua, NH 03062 Phone: 603-884-7732 Fax: 603-884-0630 Susanne.Balle(a)hp.com

2 1

Re: [ogsa-wg] More comments: HPC Use Cases -- Base Case and Common Cases
by Ian Foster 28 Apr '06

28 Apr '06

Susanne: I'd like to respond to your comments. I believe that the reference to "network partitions" refers to the fact that in a distributed environment, unlike a single machine environment, we cannot be sure that messages will be delivered: a network failure can result in any message being lost. Thus, a job submission may not receive a response, and in that case, we cannot know whether the job was submitted (i.e., the request got through, but the response was lost) or not (i.e., the request was lost). One convenient way of dealing with this problem is to allow users to associate a "unique job id" with a job request. A scheduler that receives a second or subsequent submission with the same jobid should simply return the response it provided to the first request received. It's true that a user can achieve a similar effect by searching for the submitted job in the scheduler queue. However, this approach is more complex to do, and also suffers from the problem that the job might have already completed and thus can't be found that way. In our recently circulated ESI specification, we proposed an optional "unique job id" field in JSDL as a way of addressing this requirement. This notion was discussed on a BES call, and people seemed sympathetic to the idea. Ian. At 12:20 PM 4/28/2006 -0400, Balle, Susanne wrote: >Marvin, > >Enclosed find the remaining of my comments: > >Page 5. (top paragraph) I think I know what you mean by "with the >ambiguity of distinguishing between scheduler crashes and network >partitions ". "scheduler crashes" is obvious. I am assuming that by >"network partitions" you are inferring that various sub-networks are >going to have different response time which will have an effect on the >time it takes to deliver a call-back message. > >Reading further along in the same paragraph I am now not sure I know >what you mean by "network partitions". > >Page 5. Section 3.3 >The topic of this section is clear (described in the first line of the >paragraph) but of the section is a little confusing. > >"possibility that a client cannot directly tell whether its job >submission request has been successful ..." --> Do we expect the client >to re-submit the job if the submission failed or do we expect users to >inspect that their job has in fact been submitted and resubmit if >needed? I am wondering if we assume the later if that wouldn't result in >users re-launching their jobs several time if they do not see their job >listed in some state when pulling the job scheduler for the state of >their job? > >I guess I do not understand why so much emphasis is put on the >"At-Most-Once" or "Exactly-Once". > >Can't the client poll the Job scheduler and ask the JS for a list of >jobs queued, running, terminated, failed, etc.? It might be useful for >the client to be able to submit jobs with a special keyword like >JOB_SUBMITTED_BY since that would reduce the list it gets back. It would >be nice if the value for the keyword was a unique identifier but doesn't >have to be. Most schedulers allows you to name or associate a group to >programs so that feature could be used as special keyword. > >Page 6. Section 3.4 >General question: Are you taking into account that user applications >will require different software? > >1. For example if my executable is compiled for Linux, Intel platform >then I would like to run it on a Linux,Intel system and not a Linux,AMD >system. > >2. Are you assuming that the program will be compiled on the fly on the >allocated system? or pre-compiled and then staged? > >I agree that staging the data is going to be an interesting topic. > >All this is probably out-of-band for the HPC JS Profile but should be >considered somewhere. I am sure it is I just don't know where. > >I like the section on virtual machines and think that they will be used >more and more in the future. > >Page 7. Extended Resource Features >The second approach (arbitrary resource types ...) is the only one that >make sense to me since that approach is extensible. I believe that Moab >is implementing this approach as well. > >Page 8. Extended Client/System Administrator Operations > >Are you assuming that System Administrators will be able to perform sys >admin operations on somebody else's system? I don't think that is right. > >You mention suspend-resume. Are you thinking of suspending a job running >across several clusters that are in different organizations? Or just >suspending a job on a single cluster/server? > >Again I am trying to figure out how this fit in with "One important >aspect, is that the individual clusters should remain under the control >of their local system administrator and/or of their local policies". > >I believe that suspend-resume is a JS operation or an operation to be >performed by the local sys admin, NOT by remote sys admins. > >If we are now talking about a meta-scheduler then yes it makes sense. In >the case of a meta-scheduler it might take over the individual JS and >schedule jobs base on its own policies, on its job reservation system, >etc. In this case I look at it as we have one deciding entity (the >meta-scheduler) and several "slaves". Moab and Maui are the only >meta-scheduler I an familiar with and they do take over the scheduling >decisions/node allocations/etc and just submit jobs to the local job >schedulers. > >This does of course assume that the local system administrators have >agreed on a schedule when their cluster is shared within this greater >infrastructure. This is a different approach than having jobs passed >onto their local scheduler and run on their systems. > >This just seems to be a different approach from the one that is taken in >this paper. >I might be wrong. If I am please educate me. > >Page 9. Section 3.10 > >Don't forget UPC (Unified Parallel C: http://upc.nersc.gov/) This >parallel programming paradigm is getting more and more interest from >several communities. >We'll need to provide support for UPC as well. > >Page 10. Section 3.13 >A meta-scheduler approach that make sense to me is to allow developers >to submit their job to their local cluster using their "favorite" >scheduler commands and then have the meta-scheduler load-balance the >work and forward the job to another system/cluster if needed. Moab from >cluster resources support this approach even if the clusters have >different JSs. They have a list of supported JS such as LSF, PBSpro, >SLURM, etc. and they can "translate" one JS's commands into another >within that supported set. > >Page 11. SLURM is missing. > >Let me know what you think, > >Regards > >Susanne > >--------------------------------------------------------------- >Susanne M. Balle, >Hewlett-Packard >High Performance Computing R&D Organization >110 Spit Brook Road >Nashua, NH 03062 > >Phone: 603-884-7732 >Fax: 603-884-0630 > >Susanne.Balle(a)hp.com _______________________________________________________________ Ian Foster, Director, Computation Institute Argonne National Laboratory & University of Chicago Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619. Web: www.ci.uchicago.edu. Globus Alliance: www.globus.org.

3 2

#new-4 add optional IRI/URI "matching-pattern-string" to meta-data section of an EPR Resolution Service's EPR
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #new-4 add optional IRI/URI "matching-pattern-string" to meta-data section of an EPR Resolution Service's EPR Tracker: Naming Comments by Frank Description: As we can have many different IRI/URI schema for resolvable end point identifiers with many different EPR Resolution Service implementations that only know how to deal with certain IRI/URI schema. In order for a client to know what resolution service instance to use for the EPI that it has, a matching-pattern can be associated with a resolution service instance that the client can use to match the EPI. Such a matching-pattern-string could be added the meta-data section of an EPR Resolution Service's EPR -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#new-3 add optional "Unambiguous Web Service Endpoint Profile" and/or "Web Service Endpoint Address Identifier Profile" label to meta-data section of an EPR
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #new-3 add optional "Unambiguous Web Service Endpoint Profile" and/or "Web Service Endpoint Address Identifier Profile" label to meta-data section of an EPR Tracker: Naming Comments by Frank Description: To help the EPR consumer's processing logic, the minter or any intermediate with enough knowledge about the EPR usage can add a (optional) profile label to the EPR. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

Glance will be used as well
by Andrew Grimshaw 28 Apr '06

28 Apr '06

I will be hosting a glance session for the call this morning. Ogsa.glance.net Session key: 0428 Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

1 0

FW: [ogsa-naming-wg] Call in number for tomorrow morning
by Andrew Grimshaw 28 Apr '06

28 Apr '06

All, It has been pointed out to me that I forgot to cross-post. Sorry for the late info on the call #. A _____ From: owner-ogsa-naming-wg(a)ggf.org [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Andrew Grimshaw Sent: Thursday, April 27, 2006 3:46 PM To: ogsa-naming-wg(a)ggf.org Subject: [ogsa-naming-wg] Call in number for tomorrow morning All the dial in information is 1-877-422-0033 Passcode: 348140. I've never used this number - so watch for email in the first few minutes if you cannot get in and I need to send out instructions. Recall the agenda is: Proposed Agenda: Max time Subject 5 minutes Agenda bashing 30 minutes Discuss draft requirements document including vis a vis existing draft WS-Name document 30 minutes Discuss approval of DRAFT WS-Names document to send to GFSG for GFSG approval. Note we will prepare a version that does not include the language that overlaps 5.3. 25 minutes Attempt to come to closure on working group consensus regarding WS-Directory, RNS, or failing that, at least what the issues are. Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

1 0

#new-2 resolution should optionally return referral-EPR, RR or IRI/URI
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #new-2 resolution should optionally return referral-EPR, RR or IRI/URI Tracker: Naming Comments by Frank Description: In order to support global resolution names and services, the resolution service and renewableReference should optionally be able to return an EPR to another resolution service or other RenewableReference or alternative URI. This is the referral functionality that makes DNS/LSID/Handle do their global resolution. The client can distinguish the EPRs by porttype/interface, and when a new resolution service EPR is returned instead of an expected application-svc-EPR, then the resolution of the URI should be attempted with the new resolution svc instance. Similar for RR and URI. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#new-1 zero, one or more "abstract-names"
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #new-1 zero, one or more "abstract-names" Tracker: Naming Comments by Frank Description: There is no reason to assume that there will be only one very special "abstract-name", and thus the spec should cater for 0, 1, or many. Same is true for RenewableReferences and resolution service EPRs. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#1746 epr-hint removal
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #1746 epr-hint removal Tracker: Naming Comments by Frank Description: remove the optional parameter "epr-hint" for the renewable reference because its use and associated semantics is very confusing and doesn't add functionality. If the resolver can make use of additional information in the original EPR, then the renewable reference minter can add that to the RR-EPR's Address and/or ReferenceParameters. In other words, there is no point in putting the burden on the client to "guess" whether it makes sense to communicate the original EPR or not, because the minter can do it much better. Furthermore, the burden is still on the client to verify whether the reply is a new EPR or not. Andrew Grimshaw (2006-03-16 13:47:33) I'd rather not remove it. In our experience with an earlier re-resolution scheme it is very useful to know which EPR the client has already tried ... because if they just tried an EPR and it did not work, why give them exactly the same one back? Instead, you want to give them another, "fresher" one if one is available. For example, suppose my resolution service is really a binding cache, binding abstratnames to EPR's - or if i am not using abstract names to id services, whatever i am using in the EPR to id services. Clients use the cache service to get bindings. If they don't pass in the binding they used - they may get the same one back. Frank: Please read my comment again... the epr-minter of the renewable reference EPR can embed information about the EPR in which it was embedded. Furthermore, as the client cannot compare the EPR that is returned with its cache of already used EPRs, and because the client doesn't know whether it deals with a "smart" or "dumb" resolution service, it can only just try and give up after a number of attempts if it doesn't work. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#1745 resolve-abstract-name TO IRI-to-EPR
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #1745 resolve-abstract-name TO IRI-to-EPR Tracker: Naming Comments by Frank Description: the IRI passed to the "resolve-abstract-name" should not be specific to an "AbstractName", but should be defined for generic "IRI-to-EPR" resolution. The IRI might alternatively be derived from the Address+RefParameters, or may have been communicated through many different ways that are different from EPR embedding. Andrew Grimshaw (2006-03-16 13:00:50) I disagree most strongly. The whole point of that porttype WS_Name resolveAbstractName(AbstractName) is to work with abstract names that are explicitly comparable without having to resort to using RefParameters. If someone wants to do as suggested - then they should use the other resolution port EPR resolve([EPR]) and pass in the EPR. Frank: Please read my comment again... It states that the interface should be useful for any URI/IRI, not "just" the abstract-name. In other words, "your" abstract name is just one possible URI to identify the resource and there maybe many, many more, and of those, there could be one or more that can be used to resolve. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#1744 Resolver Port Type Rename
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #1744 Resolver Port Type Rename Tracker: Naming Comments by Frank Description: change the portType name to indicate that this is a resolution to EPRs, like EprResolverInterface and EprRenewableReference, because there are many possible resolutions/resolvers and the porttype-name "Name" doesn't tell you much Andrew Grimshaw (2006-03-16 12:57:52) I'm not sure I understand the question - though I believe the spec as modified reflects the desire - i.e., that the two resolution porttypes explicitly have different "types" - one returns a WS-Name, the other a vanilla EPR. Frank: So we differentiate by return type... isn't the operation name a more intuitive way to address semantical meaning? -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#1742 WS-Name vs. Abstract Name
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #1742 WS-Name vs. Abstract Name Tracker: Naming Comments by Frank Description: remove and do not use the "WS-Name" definition as it has no more special meaning when the Address can also be viewed as an "abstract-name" Andrew Grimshaw (2006-03-16 10:54:35) I disagree. The term "WS-Name" implies an EPR with an AbstractName. Whereas a RenewableReference implies an EPR with a Resolver EPR. Frank: Please read my comment again as this has nothing to do with renewable references... A "name" is not a "EPR"... it's use as one only confuses. Furthermore, there is nothing "abstract" about the "abstract-name"... also causes confusion -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

[Fwd: [ogsa-naming-wg] Call in number for tomorrow morning]
by Frank Siebenlist 28 Apr '06

28 Apr '06

FYI - Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

Naming requirements document
by Andrew Grimshaw 28 Apr '06

28 Apr '06

All, Recall that back at the January face-to-face Frank and Dave took an action to write up their take on the requirements for (low-level) naming. Attached is their draft. A few comments of mine based on my read and discussions of the document with Dave. 1) This is not intended as a replacement for the existing work. 2) It is requirements - not specifications. Rather, it is a call for specifications that address the requirements. 3) Several of the requirements are met by the existing WS-Naming draft specification, though some are not. 4) Two of the proposed "specifications", 5.2 and 5.4 are covered by the existing WS-Name specification. A variant of 5.3 is covered in the WS-Name spec. The variant specified a technique that could be used to ensure that identifying information would be sent with the headers - specifically embed names in the reference parameters. Personally I fell that 5.3 is a fine replacement for that if desired. 5.1 is not covered at all, and I must confess that it seems so obvious that I had implicitly assumed it true. Dave says it is not - so having a spec that says it must be true seems ok to me. 5) I think that with a small amount of work on this document and the WS-Name spec we can make them dovetail quite nicely. GGF is a scant two weeks away. I'd like to schedule a teleconference with the following agenda on Friday April 28th, at 10 AM eastern. (Dial in information as soon as I find a dial in number we can use.) If you plan on attending, PLEASE read both the existing draft WS-Name spec and this document before the call. Proposed Agenda: Max time Subject 5 minutes Agenda bashing 30 minutes Discuss draft requirements document including vis a vis existing draft WS-Name document 30 minutes Discuss approval of DRAFT WS-Names document to send to GFSG for GFSG approval. Note we will prepare a version that does not include the language that overlaps 5.3. 25 minutes Attempt to come to closure on working group consensus regarding WS-Directory, RNS, or failing that, at least what the issues are. Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

3 2

no authz SoW yet...
by Frank Siebenlist 27 Apr '06

27 Apr '06

Sorry, it requires a little more homework on my part... -Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

URLs for 4/27 OGSA call (info model item)
by Ellen Stokes 26 Apr '06

26 Apr '06

A document has been added: "BES and JSDL": https://forge.gridforum.org/docman2/ViewProperties.php?group_id=42&category… Note: the one thing I left off the next steps slide above is a work item to provide a concrete simple diagram and xml example to demonstrate the approach "updated JSDL 1.0 to CIM spreadsheet": https://forge.gridforum.org/docman2/ViewProperties.php?group_id=42&category… Ellen

1 0

Proposed agenda for April 27th call
by Hiro Kishimoto 26 Apr '06

26 Apr '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 27th Thursday from 8:30am - 10:30am (CDT). Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0427 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call OGSA webcast report (Jem) Telecon minutes approval (if available) Action Items status review (see the bottom of this email) Agenda bashing 2) Frank's statement of security work review (Jay, if available) Frank will send out his statement of security work proposal. It is expected to be the base of new specification. 3) Information model discussion (Ellen and Fred, 30 min) > - Ellen will do a revised visio diagram that has only the > relevant BES attributes and JSDL attributes (base it off > the info_model_for_BES/BES Container class) 4) GGF17 OGSA session preparation (Hiro, 20 min) OGSA-WG will have two sessions: (1) OGSA Information Model (G405) Thursday, May 11, 1:45 pm - 3:15 pm (2) OGSA EMS architecture (G405) Thursday, May 11, 3:45 pm - 5:15 pm Hiro will give opening keynote on OGSA Wednesday, May 10, 9:30 am - 10:30 am 5) OGSA interim F2F meetings after GGF17 date/location (Hiro, 20 min) Hiro will send out list of options before the call. 6) Wrap up (10 min) AOB <*NEXT CALL*> May 1, 4, 8 NO call GGF17 May 10-12 in Tokyo <*ACTION ITEMS*> From April 20 call - Marvin will re-format and update the use case document - Marvin will initiate mail discussions on the extension topics - Marvin to send the draft charter to the OGSA list for comments. (Final review will be at the BOF in Tokyo.) - Dave B will send out the scenarios (written by the data team) to HPC team - Marvin and Dave B to send out and continue the Data scenario discussion on the list From April 6 F2F meeting - Hiro and Jun will look at what needs to be provided as a set of common component models and make a proposal to the group. - Steven will update the scenarios with the comments from this review and merge into the draft Scenarios document From April 5 F2F meeting - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. - Manuel & Andrew to determine where/when to hold standard hierarchical namespaces discussions. From April 4 F2F meeting - Steven Newhouse to ask Jennifer Schopf on the status of the GIN modeling document. - Ellen will do a revised visio diagram that has only the relevant BES attributes and JSDL attributes (base it off the info_model_for_BES/BES Container class) Other - Andreas: to finalize OGSA WSRF BP 1.0 doc and make a final call Deferred - Jay check and find out relatively small funding to Globus to develop document on their security work (April 6 F2F) - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (April 4 F2F) --- Hiro Kishimoto

1 1

FW: [wg-all] An invitation to the OGSA webcast on April 26th
by Treadwell, Jem 26 Apr '06

26 Apr '06

Hi, Just a reminder that this webcast is today (Wednesday) - as of Tuesday morning there were still a few places available, so please pass this on to anyone you know who may be interested. Also please note that the virtual classroom software was upgraded over the weekend, so if you've registered please visit the "testsetup" link or log in for the session a few minutes early as you will need to download new client software. Thanks! - Jem -----Original Message----- From: owner-wg-all(a)ggf.org [mailto:owner-wg-all@ggf.org] On Behalf Of Steve Crumb Sent: Tuesday, April 18, 2006 10:47 PM To: GRID-announce(a)ggf.org; wg-all(a)ggf.org Subject: [wg-all] An invitation to the OGSA webcast on April 26th The GGF's OGSA Working Group invites you to join our webcast session, "Defining the Grid: An Introduction to the Open Grid Services Architecture," on Wednesday April 26th at 2pm EDT. In this webcast we will discuss the evolution of grid computing, explain how service-oriented grids fit with other leading-edge enterprise technologies, and describe OGSA and its core capabilities. The presentation will be given by Professor Andrew Grimshaw of the University of Virginia, a leading member of GGF and the OGSA Working Group. After the presentation Andrew and other members of the Working Group will be pleased to answer your questions. This webcast will be of interest to technology managers, architects and developers who would like to learn about standards-based grid technology and its place throughout the enterprise. For more details, and to register, please visit http://www.presentationselect.com/hpinvent/detailsl.asp#1188. Registration is open to all, and there is no charge. Places are limited, however, so be sure to register early. And don't worry if you can't make it to the live webcast: a recording of the session will be available a few days after the event. Please watch http://www.ggf.org for details. Steve Crumb Executive Director, GGF scrumb(a)ggf.org +1 630-252-8610 +1 630-915-3324 (cell)

1 0

Job State proposal made to SAGA-RG
by Christopher Smith 25 Apr '06

25 Apr '06

Hi all, Per Marvin's comments ... Here is a pointer to the proposal for modelling job states that I made to the SAGA group last February. http://www-unix.gridforum.org/mail_archive/saga-rg/2006/02/msg00107.html -- Chris

5 11

FW: Comments to the HPC Use Cases: Base Case and Common Cases
by Balle, Susanne 25 Apr '06

25 Apr '06

-----Original Message----- From: Marvin Theimer [mailto:theimer@microsoft.com] Sent: Monday, April 24, 2006 9:06 PM To: Balle, Susanne Cc: Treadwell, Jem; Marvin Theimer Subject: RE: Comments to the HPC Use Cases: Base Case and Common Cases Hi; Thanks for your input! My comments on your comments are in-line. How do you feel about my posting this email to the ogsa-wg mailing list so that others can see the issues you've raised plus my responses? No problem if you'd rather not, but I think it would be interesting to the larger community if you do feel comfortable with it. Let me know -- I will keep this email thread private until you tell me otherwise. Marvin. -----Original Message----- From: Balle, Susanne [mailto:Susanne.Balle@hp.com] Sent: Monday, April 24, 2006 4:44 PM To: Marvin Theimer Cc: Balle, Susanne; Treadwell, Jem Subject: Comments to the HPC Use Cases: Base Case and Common Cases Marvin, I read the document "HPC Use Cases: Base Case and Common Cases" and thought it was a good start. I do have a couple of comments about the documents which I have enclosed below: 1. I would re-title the document to "HPC Job Scheduling Use Cases -- Base Case and Common Case". The main reason is that too many topics which are important to HPC are "out-of-band" areas with regards to the focus of this document. The document does only focus on job scheduling so why not just cal it that? [MT] Good point. I'll try it and see how others react. 2. Under Base Case In this section I would like to add a point about "users being able to query for available resources". I do that all the time before I launch a job. It is nice to know what resources are currently available or currently up so that I don't submit a job for 512 nodes and only 510 of the 512 nodes are up. [MT] This seems reasonable. A key thing will be to define what the "minimal" set of useful information is. Additional "commonly desired" information should then be defined as common case extensions. 3. Page 3 (top). Reading this Section made me decide that renaming the document made more sense. This is NOT "HPC Use Cases" but "HPC Job Scheduling Base Cases". This will allow others to follow your lead and create "HPC Other topic (.ie. Data management, etc.) Use Cases". [MT] Agreed. 4. Page 3 (bottom). One important aspect that you have left out here is that the individual clusters should remain under the control of their local system administrator and/or of their local policies. You cannot impose a FIFO policy onto clusters with a different scheduling policy. [MT] You raise a good point. My goal in specifying FIFO was to say that the "simplest" scheduling policy would be the only thing "required" of all schedulers. But I think the true base case is that a scheduler is free to pick whatever scheduling policy (or policies) that it wishes. I.e. that specification of required scheduling policies is out-of-scope for the base case. 5. Page 3 (bottom) I am not quick sure what you mean by "the only scheduling policy supported is FIFO". Where do you mean? Aren't you planning on passing the jobs onto the local scheduler which will then apply whatever policy it is set to obey? Do you mean that in the scheduler infrastructure you want to create you will only support FIFO which in fact will just consist in passing it on to the local scheduler? I am a little confused after reading this section. [MT] My comment to point 4 is applicable here. My goal was to define the "smallest" or "simplest" set of interop requirements possible for the base case. Extensions could then define scheduling policies that a scheduler promises to provide. Does "only supporting FIFO" mean that you will only submit one job at the time to a cluster? [MT] No, if more than one job will fit on the cluster then there is no reason not to run two or more jobs simultaneously. But I'm changing the base case to not require any particular scheduling policy in any case. 6. " A job consists of a single program running on a single node". I believe this is too restrictive. MPI programs need to be considered to make sure that we have the right level of confidence that the design/infrastructure will work for parallel programs as well. How about OpenMP or threaded programs? Have you taken this type of programs into consideration? I do not see them mentioned anywhere. [MT] These fall under the "common cases that will be handled via extensions" category. Note that support for MPI programs typically involves infrastructure (such as SMPD daemons) that not all scheduling systems necessarily support; hence MPI programs are not explicitly supported in the base case. The whole purpose of defining the various common cases in the next section of the document is to ensure that we address how to handle things like MPI programs correctly by means of thought-out extensions. The same applies for threaded/OpenMP programs. 7. After having read Section 2 I believe that the common case is too restrictive. I understand that you want things to be simple but maybe they have become too simple. I am worried that you cannot extend this simple base case to fit most common requirements for HPC applications. [MT] Figuring out how to extend the base case to cover all the listed common cases is the task of the working group. :-) Personally I believe that we can define suitable extensions that will enable the simple base case I've defined to be extended to the common cases. If that's not the case then we'll certainly change the base case as necessary. But I want to start with the simplest possible base case since it's a constant battle to keep peoples' pet features out of the base design and it's a slippery slope to hell once you step away from the absolutely most minimal base case that lets the whole edifice (base case plus extensions) hang together. 8. Section 3.1 You forgot SLURM in the list and also Moab which is the commercial product from Cluster Resources who support Maui. Moab's Grid scheduler is very interested and offers a lot of very desirable features for a Grid environment. More info on SLURm is available at: http://www.llnl.gov/linux/slurm/slurm.html I am working on SLURM and would be happy to provide you with what you need for your document or to answer any questions you have about SLURM. [MT] Great! I really appreciate it. I have some more comments on the remaining sections. I will send them in a separate email tomorrow. Regards Susanne ----------------------------------------- Susanne M. Balle Hewlett-Packard High Performance Computing R&D Organization MS ZKO01-3 110 Spit Brook Road Nashua, NH 03062 Phone: 603-884-7732 Fax: 603-884-0630 Susanne.Balle(a)hp.com

1 0

Teleconference minutes - 24 April 2006
by Andreas Savva 25 Apr '06

25 Apr '06

Attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060424/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 24 April 2006 =================================== * Participants Mike Behrens (R2AD, LLC) Chris Jordan (SDSC) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Andreas Savva (Fujitsu) Frank Siebenlist (ANL) Jem Treadwell (HP) Jay Unger (IBM) Minutes: Andreas Savva * April 20 minutes approved with no changes * Action review [Only items with updates are listed below] - Jay will ask Frank to summarize in a 1-2 pages what work exists and can be the base of new specifications. (This summary will be then reviewed by the group and decide whether that is the way to go.) Done (today's agenda) - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. Hiro sent follow up email to Marvin. - Ellen will do a revised visio diagram that has only the relevant BES attributes and JSDL attributes (base it off the info_model_for_BES/BES Container class) Confirmed that there will be an update in time for this Thursday's call. - Andreas: to finalize OGSA WSRF BP 1.0 doc and make a final call In progress. * Security Frank said there will be an AuthZ WG call tomorrow to discuss re-chartering and David Chadwick's documents. Discussed what kind of security work has already been done (implemented) and could become the basis of a new specification. Frank talked about a proposal for an authorization call-out WS interface that could end up as a GGF published specification: - This is a call-out from a security infrastructure (e.g., from a container in the case of Apache). In GT there is an internal API around the notion of a PDP and some PDPs are configured to call out. These call-outs use a WS interface and SAML 1.1 at the moment. - The work plan would possible extent this authorization call out i/f and define a new WS protocol. ACTION: Frank to write up and send to the list a one page summary of the authorization call-out proposal before Thursday's call. The group will discuss the proposal on the list and either on the Thursday call or at a later teleconference. (Frank cannot make the Thursday call but if Jay is present he will explain it instead.) * GGF17 session review Two sessions are planned: Information and EMS - There is no detailed agenda yet for either yet. - In the Information session the likely plan is to present the latest work as agreed at the last F2F (abstract view for job requirements matching) and connection of that work to JSDL and RSS. - Jay has sent a request to the JSDL-WG and RSS-WG chairs to get some time in those WGs sessions but has not received confirmations yet. ACTION: After confirming the agenda of this session, Hiro/Jay to send an invitation to those groups to also attend the Information Modeling session. - (And, possibly, to suggest continuing this discussion in those WG's sessions.) - For the EMS session a likely agenda is - Scenarios review (If Steven has a conflict Andreas may fill in.) - CDDLM and JSDL relationship - WS-Agreement discussion - Jay suggested discussing how to use WS-Agreement (e.g., role and relation between WS-Agreement and JSDL) and to also invite people from GRAAP-WG. He said that an opinion he has heard often is that the framework described by WS-Agreement is interesting but it is not clear how to use it. - Hiro and Andreas mentioned that Business Grid and NAREGI use WS-Agreement in certain places. They'll look into getting some material for this discussion. - Andreas has seen a list of projects that use WS-Agreement and he will send it to Jay. - Another candidate topic for the EMS session is an ESI discussion. But the BES-WG has already started discussing the ESI paper and they seem to be making good progress. There was also a suggestion to do an ad hoc BoF. So it was agreed to encourage the idea of an ad hoc BoF instead of using time in the EMS session. - OGSA dinner: It's likely that there are other events planned for Wednesday and Thursday night (reception, chair appreciation). And some people may be leaving Friday. Hiro will confirm the schedule. * Webcast update - Jem talked about the final preparations. The slides are ready but some minor revisions may still be made. - The webcast recording should be made available online a few days after the event, and definitely by GGF17.

1 0

Senior grid engineer position in Charlottesville
by Andrew Grimshaw 24 Apr '06

24 Apr '06

The University of Virginia, Department of Computer Science's Virginia Center for Grid Research has an opening for a senior Grid engineer. Master's degree or equivalent required; also, the following are required: 3 years experience in using Legion grid system software; 5 years experience in developing and maintaining grid or distributed computing software, particularly using C++; strong technical writing experience (in English); strong communications skills; and, ability to travel, both domestically and internationally. Responsibilities of the senior grid architect include, but are not limited to: research into grid system design and architecture as well as guiding related research of students; design and implementation of extensions to Legion grid system software; design, development and deployment of grid enabled applications running on Legion grid software; deployment, maintenance and troubleshooting of grid systems using Legion grid software; writing of research proposals and peer reviewed technical papers for Center; and, developing and maintaining collaborations with both internal (UVA) and external collaborators. To apply, send vita and contact information to: Andrew Grimshaw Department of Computer Science University of Virginia 151 Engineers Way Charlottesville, VA 22904 or email at: grimshaw(a)virginia.edu The University of Virginia is an Equal Opportunity/Affirmative Action Employer.

1 0

Proposed agenda for April 24th call
by Hiro Kishimoto 22 Apr '06

22 Apr '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 24th Monday from 5pm to 7pm (CDT). Per Ellen's request, "information modeling" session is moved to Thursday April 27th. The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0424 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (April 20th) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060420 Action Items status review (see the bottom of this email) Agenda bashing 2) OGSA security discussion (if Frank is available, 20 min) OGSA security design team process > Follow up action on Security: Jay will ask Frank to > summarize in a 1-2 pages what work exists and can be the base of > new specifications. (This summary will be then reviewed by the > group and decide whether that is the way to go.) OGSA-AuthZ-WG status update 3) GGF17 OGSA session preparation (Hiro, 20 min) OGSA-WG will have two sessions: (1) OGSA Information Model (G405) Thursday, May 11, 1:45 pm - 3:15 pm (2) OGSA EMS architecture (G405) Thursday, May 11, 3:45 pm - 5:15 pm Hiro will give opening keynote on OGSA Wednesday, May 10, 9:30 am - 10:30 am 4) OGSA webcast preparation (Jem, 20 min) Update on Wednesday's webcast 5) Wrap up (10 min) AOB <*NEXT CALL*> April 26 (Wed 1-2:30pm CDT) OGSA webcast on air April 27 (Thu 8:30-10:30am CDT) Information Model (Fred and Ellen) GGF17 preparation May 1, 4, 8 NO call GGF17 May 10-12 in Tokyo Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ <*ACTION ITEMS*> From April 20 call - Marvin will re-format and update the use case document - Marvin will initiate mail discussions on the extension topics - Marvin to send the draft charter to the OGSA list for comments. (Final review will be at the BOF in Tokyo.) - Dave B will send out the scenarios (written by the data team) to HPC team - Marvin and Dave B to send out and continue the Data scenario discussion on the list From April 17 call - Jay will ask Frank to summarize in a 1-2 pages what work exists and can be the base of new specifications. (This summary will be then reviewed by the group and decide whether that is the way to go.) From April 6 F2F meeting - Hiro and Jun will look at what needs to be provided as a set of common component models and make a proposal to the group. - Steven will update the scenarios with the comments from this review and merge into the draft Scenarios document From April 5 F2F meeting - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. - Manuel & Andrew to determine where/when to hold standard hierarchical namespaces discussions. From April 4 F2F meeting - Steven Newhouse to ask Jennifer Schopf on the status of the GIN modeling document. - Ellen will do a revised visio diagram that has only the relevant BES attributes and JSDL attributes (base it off the info_model_for_BES/BES Container class) Other - Andreas: to finalize OGSA WSRF BP 1.0 doc and make a final call Deferred - Jay check and find out relatively small funding to Globus to develop document on their security work (April 6 F2F) - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (April 4 F2F) --- Hiro Kishimoto

1 0

Teleconference minutes - 20 April 2006
by Andreas Savva 21 Apr '06

21 Apr '06

Minutes attached. This was mainly an HPC profile call. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060420/en/1 -- Andreas Savva OGSA Teleconference - 20 April 2006 =================================== * Participants Susanne Balle (HP) Dave Berry (NeSC) Mathias Dalheimer (Fraunhofer) Marty Humphrey (UVa) Chris Jordan (SDSC) Hiro Kishimoto (Fujitsu) Mark Morgan (UVa) Duane Merrill (UVa) Andreas Savva (Fujitsu) Stuart Schaefer (Softricity) Chris Smith (Platform) David Snelling (Fujitsu) Jun Tatemura (NEC) Marvin Theimer (Microsoft) Jem Treadwell (HP) Glenn Wasson (UVa) Minutes: Andreas Savva * Summary of new actions Action: Marvin will re-format and update the use case document Action: Marvin will initiate mail dicsussions on the extension topics Action: Marvin to send the draft charter to the OGSA list for comments. (Final review will be at the BOF in Tokyo.) Action: Dave B will send out the scenarios written by the data team. Action: Marvin and Dave B to send out and continue the Data scenario discussion on the list * Review of existing actions [Only the actions that were updated are listed below.] - Andreas to update OGSA web site with new teleconference information. (DONE) - Jay/Jem/<your name here> to provide three examples of customers grid deployments/usages (without attribution/names) in two dimensions. (DONE) - Jun and Dejan will take this issue (with or without host name in JSDL document) back to the CDDLM-WG for discussion. (DONE) See CDDLM discussion in these minutes. - Webcast Participants: send bios and photo to Jem. - Jem will follow up with the panelists. - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. Missing context for this action. Hiro and Marvin will talk about it offline to clarify what needs to be done. - Tom: to finalize OGSA WSRF BP 1.0 doc and make a final call - Andreas volunteered to pick up this action and update the document. * HPC profile discussion led by Marvin Theimer ** Close out the use cases. - No disagreements raised with base/common case classification. Therefore no major changes are required. - Document still needs to be reformated (GGF template) and also revised according to the April F2F discussion (e.g., add requirements). Action: Marvin will re-format and update the use case document ** Start discussing extension mechanisms. Marvin kicked off the discussion with a description of the 4 different types of extensions he envisages: - WSDL extension: adding additional wsdl operations to a spec. (e.g., extending the BES specification to include a migrate operation.) - State Diagram extension--- See email by Chris Smith to the Saga-WG http://www-unix.gridforum.org/mail_archive/saga-rg/2006/02/msg00107.html - Extending the set of understood descriptions (Infoset extension) E.g., extending resource descriptions in JSDL to support new resource types. (comment: how it relates to CIM) - Factoring into composable micro-specs (for protocol composition and extension) Dave S noted that things can become very complicated since the various specs may also define optional features, e.g., optional elements in resource descriptions. Also we have to be sensitive to what each spec thinks is the proper way to extend it. (One example is JSDL and its relation to scheduling attributes; or notification subscription and whether it should be part of a jsdl document, or provided by a new extended operation). There is always 'tension' when making choices where to place things. Action: Marvin will initiate mail dicsussions on the extension topics ** As part of that, discuss how the Snelling/Foster ESI design might fit into things. Technical discussion was postponed. It was proposed that instead of having a separate discussion to join the discussion already started in the BES-WG. The ESI authors also plan to do all their discussions in the BES-WG. It was agreed that all people participating in the HPC profile discussion should be on the following lists: - OGSA, OGSA-BES, JSDL and (optionally) SAGA-WG ** Review WG charter draft The draft charter was sent to Hiro and to Marty Humphrey (proposed co-chair) for comments. Some changes have already been proposed. Discussed some parts of the charter: - WG might choose to do simple specs, if it identifies things that are needed. - Should it be in the Compute or Architecture area? Agreed that Compute is better. - Planning two documents - Use case: first draft (Apr), submission (Jul), publication (Sep) - Profile: first draft (aug), submission (Nov), publication (Mar) - It is important to converge on a (draft) spec by August. - Marvin expects that there will be some prototype implementations in autumn (accepting the risk of changes from first draft) - There will also probably be an interop exercise in November. - Marvin is trying to get as many existing groups (globus, condor, altair, platform, ...) as possible to join the effort. But it is not a prerequisite that every possible stakeholder in this area agrees to participate in this effort. - Use case document: Susanne volunteered to provide a section on an open source scheduler project. [missed name] Action: Marvin to send the draft charter to the OGSA list for comments. (Final review will be at the BOF in Tokyo.) ** Data services relation Dave Berry described the work the OGSA Data WG is doing in developing data scenarios (e.g., pipelining, and parameter sweep.) The Data team would like some input from EMS on how to do the job submission; and also what should the relation of their work to HPC profile be. - Discussing the parameter sweep scenario, Marvin agreed that there are different ways of doing it: by a higher level service or by extended job (jsdl) descriptions. It is not clear yet which way it is better. But initially a higher level service that submits individual, simple, jsdl documents seems better than coming up with complex job descriptions including definition of dependencies. (This might be a later step.) - Dave B also said that it may be time to start trying to thinking about what to do with workflow Should the data team contribute these scenarios to the HPC Profile work? - Marvin welcomes all feedback to the HPC Profile. Action: Dave B will send out the scenarios written by the data team. Action: Marvin and Dave B to send out and continue the Data scenario discussion on the list * CDDLM joint discussion Discussed 'lazy' issue: - It is up to the implementation of the (deployment) service what to do with properties, etc, marked 'lazy'. The implementation may choose to ignore any added values for properties marked as lazy. - It was clarified that a user may redefine the value of lazy to false and therefore pass in desired value. * Webcast update The webcast was announced and within the first day 85 people registered. This is half the capacity so places are filling in fast. Some members mentioned they had problems trying to use the HP webcase site from Macs (no activex). - Dave S is out of office on the webcast day and probably cannot make it. - It has not been possible to contact Tom Maguire. At the moment the panel looks likely to be made by Andrew Grimshaw, Jem Treadwell, Hiro Kishimoto, Chris Jordan, Jay Unger.

1 0

Slides uploaded/logistics for Thursday's webcast dry run
by Treadwell, Jem 20 Apr '06

20 Apr '06

Hi, I've uploaded the latest set of updates to the slides - you can find them at http://tinyurl.com/lvoac. This set includes Andrew's updates, with some changes to look & feel, and a new slide for Information Services (Slide 56), which will need some review. The only area that we need to add coverage for now is Data. The Dry Run is scheduled for Thursday at 6pm EDT - *not* during the regular telecon. Anybody who wants to join in the dry run is more than welcome, but please let me know in advance to make sure that I allocate enough places in the virtual room. Here are the logistics for joining Thursday's dry run: * You need to install and test the virtual room software *before* you join the event. Please do this now by using this link, preferably with Internet Explorer: * https://www.rooms.hp.com/testsetup <https://www.rooms.hp.com/testsetup> * To join the Dry Run event (after 5:30pm EDT): * https://www.rooms.hp.com/attend/default.aspx?key=EP7XLCDCUW <https://www.rooms.hp.com/attend/default.aspx?key=EP7XLCDCUW> * Dial-in number: Toll Free: 866-880-2750 Toll: 702-477-6005 PIN: 67016# * Sorry, I don't have a toll-free non-US number for this. I just heard that we have 85 people registered 24 hours after the announcement went out, so the places are filling up fast. Thanks! - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com>

1 0

Teleconference minutes - 17 April 2006
by Andreas Savva 18 Apr '06

18 Apr '06

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060417/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference Minutes - 17 April 2006 =========================================== * Participants Jay Unger (IBM) Jem Treadwell (HP) Andreas Savva (Fujitsu) Mark Morgan (UVa) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Chris Jordan (SDSC) Andrew Grimshaw (UVa) Mike Behrens (R2AD, LLC) Minutes: Andreas Savva * Summary of new actions Follow up action on Security: Jay will ask Frank to summarize in a 1-2 pages what work exists and can be the base of new specifications. (This summary will be then reviewed by the group and decide whether that is the way to go.) ACTION: Andrew will followup with Dave Berry to produce the data slides. ACTION: Hiro to talk with Steve Crumb and arrange to send out the announcement immediately. * April 10 minutes approved no changes * OGSA interim meeting 14 minutes - Day 1 minutes approved with no changes - Day 2 (am, pm) approved with no changes - Day 3 (am, pm) approved with no changes - Day 4 approved with no changes Follow up action on Security: Jay will ask Frank to summarize in a 1-2 pages what work exists and can be the base of new specifications. (This summary will be then reviewed by the group and decide whether that is the way to go.) * Review of actions From April 10 telecon - Hiro: to ask Marvin if we can add webcast dry run to April 17 call. - The HPC profile discussion was scheduled for April 20. From April 5 pm F2F meeting - Webcast Participants: send bios to Jem. - Hiro has sent his bio. - Other participants are still been confirmed. - Participants should also send Jem their photos - Frank: to inform Jem about his availability for webcast on air - Frank can attend. - Also Jay and Dave Snelling can also probably attend. - No response yet from Tom. - Dave Berry cannot attend. ACTION: Andrew will followup with Dave Berry to produce the data slides. Other - Tom: to finalize OGSA WSRF BP 1.0 doc and make a final call. - Still pending. * Webcast slides review - Polls: Only one question is allowed per poll and the polls can only be done inline. A short time is provided to reply to the poll and the webcast continues after that. - An alternative is to do a survery afterwards using a different tool (e.g., zoomerang) - Jem asked for a few just-in-case seed questions: Jay, Mike volunteered to provide some. Other people's input is also welcome. Reviewed and made minor revisions to the slides. The slide deck is almost complete but some slides need more work. (Person in charge is named on the slide.) Jem will upload the revised slide deck to gridforge. The dry run is scheduled for, Thursday, April 20, 6-8pm EST / Friday 7-9am JST. It is now urgent to send out the webcast announcement within GGF. The announcement should be sent out on its own and not combined with other announcements. ACTION: Hiro to talk with Steve Crumb and arrange to send out the announcement immediately.

1 0

Proposed agenda for April 20th call
by Hiro Kishimoto 18 Apr '06

18 Apr '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 20th Thursday from 8:30am - 10:30am (CDT). Thanks Ian and ANL for continue providing Thursday tele-conf bridge! Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0420 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (if available) Action Items status review (see the bottom of this email) Agenda bashing 2) HPC profile discussion (Marvin, 40 min) - Close out the use cases. - Start discussing extension mechanisms. - As part of that, discuss how the Snelling/Foster ESI design might fit into things. - Review WG charter draft 3) Joint CDDLM discussion (Jun and Dejan, 30 min) From April 6 F2F minutes; > From EMS point of view, we need to define a set of common component > models, as they do exist in current implementations, but not in a > published definition document. In other words there is no standard > definition of such common components. > Action: Hiro and Jun will look at what needs to be provided and make a > proposal to the group. > The group discusses the consequences for a CDL enabled system when > the user submits a JSDL document with either a specific host name or no > host name at all, in an environment where the component model in the > CDL system provides CDL templates with cdl:lazy host binding. > Jun explained that this issue was not discussed before and the current > specification would not allow for a CDL definition that has the host as > cdl:lazy and for that value to be supplied by the caller of the Deployment > Service. > Action: Jun and Dejan will take this issue back to the CDDLM-WG for > discussion. > The group discusses the roles and responsibilities of where to define how > to deploy a particular application and which information is needed to do > so, and where or which instance is to provide this concrete information to > enable a successful deployment of a requested application > Action: Steven will update the scenarios with the comments from this > review and merge into the draft Scenarios document 4) EMS arch scenarios document update (Steven, 30 min) 5) Wrap up AOB <*NEXT CALL*> April 20 (Thu 5-7pm CDT) OGSA webcast dry run April 24 (Mon 5-7pm CDT) Information Model (Fred and Ellen) Security (Frank) April 26 (Wed 1-2:30pm CDT) OGSA webcast on air April 27 (Thu 8:30-10:30am CDT) GGF17 preparation May 1, 4, 8 NO call GGF17 May 10-12 in Tokyo Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ <*ACTION ITEMS*> From April 10 telecon - Andreas to update OGSA web site with new teleconference information From April 7 F2F meeting - Jay/Jem/<your name here> to provide three examples of customers grid deployments/usages (without attribution/names) in two dimensions From April 6 F2F meeting - Jay check and find out relatively small funding to Globus to develop document on their security work (*deferred*) - Hiro and Jun will look at what needs to be provided as a set of common component models and make a proposal to the group. - Jun and Dejan will take this issue (with or without host name in JSDL document) back to the CDDLM-WG for discussion. - Steven will update the scenarios with the comments from this review and merge into the draft Scenarios document From April 5 F2F meeting - Webcast Participants: send bios and photo to Jem. - Marvin to send e-mail that explains concerns on compliance suite by GGF & EGA. - Manuel & Andrew to determine where/when to hold standard hierarchical namespaces discussions. From April 4 F2F meeting - Steven Newhouse to ask Jennifer Schopf on the status of the GIN modeling document. - Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. (*deferred*) - Ellen will do a revised visio diagram that has only the relevant BES attributes and JSDL attributes (base it off the info_model_for_BES/BES Container class) Other - Tom: to finalize OGSA WSRF BP 1.0 doc and make a final call -- Hiro Kishimoto

1 0

New webcast slides uploaded
by Treadwell, Jem 18 Apr '06

18 Apr '06

Hi, I've uploaded a new slide set to http://tinyurl.com/rktfy. I *do* expect that these will change again on Monday, so I guess I'll be violating the 24-hour rule anyway :0) If you're producing or editing slides and you haven't yet started, please start with this deck. Everyone have a great weekend/holiday... - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com>

1 2

Proposed agenda for April 17th call *CORRECTION*
by Hiro Kishimoto 17 Apr '06

17 Apr '06

Hi all, By mistake I send it out for April 20th call. It is for 17th (TODAY). The call will start within one hour, my bad. We will move HPC profile discussion to this Thursday. Thus today's call will focus webcast slides review. The following is a proposed agenda for OGSA-WG telecon on April 17th Monday from 5pm to 7pm (CDT). If necessary, we will extend the call a little. ATTENTION: From April 10th and onward, weekly telecon day/time will change as following; - Monday: 6-8pm EDT, 5-7pm CDT, 3-6pm PDT, 11pm-1am UK, 7-9am JST - Thursday: 9:30-10:30am EDT, 8:30-10:30am CDT, 6:30-8:30am PDT, 2:30-4:30pm UK, 10:30pm-12:30am JST The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0420 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval F2F meeting minutes approval Action Items status review (see the bottom of this email) Agenda bashing 2) OGSA webcast slide review (100 min, Jem and Andrew) Jem will send out revised slide 24H before the call. Current slides are available at: https://forge.gridforum.org/projects/ogsa-wg/document/OGSA_Webcast_slides_d… OGSA webcast (April 26 Wed 2-3:30pm EDT) slide review. 3) Wrap up AOB <*NEXT CALL*> April 20 (Thu) HPC profile (Marvin) EMS scenarios (Steven) Joint CDDLM session (Dejan and Jun) April 24 (Mon) Information Model (Fred and Ellen) Security (Frank) April 26 (Wed, 2-3:30pm EDT) OGSA webcast on air April 27 (Thu) GGF17 preparation May 1, 4, 8 NO call GGF17 May 10-12 in Tokyo Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ <*ACTION ITEMS*> From April 10 telecon - Hiro: to ask Marvin if we can add webcast dry run to April 17 call. From April 5 pm F2F meeting - Webcast Participants: send bios to Jem. - Frank: to inform Jem about his availability for webcast on air Other - Tom: to finalize OGSA WSRF BP 1.0 doc and make a final call -- Hiro Kishimoto

1 0

Minutes, minutes, minutes, ...
by Andreas Savva 17 Apr '06

17 Apr '06

All the minutes of April 4-7 meeting are now on gridforge. Thanks to Jem, Fred, and Michel for helping out. https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-f2f-minutes-2006… https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-f2f-minutes-2006… https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-f2f-minutes-2006… https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-f2f-minutes-2006… https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-f2f-minutes-2006… https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-f2f-minutes-2006… I've also uploaded the minutes of the last teleconference (April 10): https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060410/en/1 -- Andreas Savva Fujitsu Laboratories Ltd

1 0

Proposed agenda for April 20th call
by Hiro Kishimoto 15 Apr '06

15 Apr '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 20th Monday from 5pm to 7pm (CDT). If necessary, we will extend the call a little. ATTENTION: From April 10th and onward, weekly telecon day/time will change as following; - Monday: 6-8pm EDT, 5-7pm CDT, 3-6pm PDT, 11pm-1am UK, 7-9am JST - Thursday: 9:30-10:30am EDT, 8:30-10:30am CDT, 6:30-8:30am PDT, 2:30-4:30pm UK, 10:30pm-12:30am JST The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0420 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (if available) F2F meeting minutes approval (if available) Action Items status review (see the bottom of this email) Agenda bashing 2) HPC profile discussion (Marvin, 60 min) 3) OGSA webcast slide review (60 min, Jem and Andrew) Jem will send out revised slide 24H before the call. Current slides are available at: https://forge.gridforum.org/projects/ogsa-wg/document/OGSA_Webcast_slides_d… OGSA webcast (April 26 Wed 2-3:30pm EDT) slide review. 4) Wrap up AOB <*NEXT CALL*> April 20 (Thu) EMS scenarios (Steven) Joint CDDLM session (Dejan and Jun) April 24 (Mon) Information Model (Fred and Ellen) Security (Frank) April 26 (Wed, 2-3:30pm EDT) OGSA webcast on air April 27 (Thu) GGF17 preparation May 1, 4, 8 NO call GGF17 May 10-12 in Tokyo Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ <*ACTION ITEMS*> From April 10 telecon - Hiro: to ask Marvin if we can add webcast dry run to April 17 call. From April 5 pm F2F meeting - Webcast Participants: send bios to Jem. - Frank: to inform Jem about his availability for webcast on air Other - Tom: to finalize OGSA WSRF BP 1.0 doc and make a final call -- Hiro Kishimoto

1 0

OGSA architecture and glossary 1.5 public comment
by Hiro Kishimoto 14 Apr '06

14 Apr '06

Hi all, As you may already know, both OGSA architecture and glossary 1.5 are now under public comment review. These document are revised version of previous 1.0 and incorporating recent developments including OGSA profile, OGSA-data, naming, etc. They are so-called our "base document." Please take time to read them and post your feedback before May 9th. http://www.ggf.org/gf/docs/?public_comment We value your feedback! Thanks, -- Hiro Kishimoto

1 0

Proposed agenda for April 13rd call (5-7pm CDT)
by Hiro Kishimoto 13 Apr '06

13 Apr '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 13rd Thursday from 5-7pm (CDT). ATTENTION: From April 10th and onward, weekly telecon day/time will change as following; - Monday: 6-8pm EDT, 5-7pm CDT, 3-6pm PDT, 11pm-1am UK, 7-9am JST - Thursday: 9:30-10:30am EDT, 8:30-10:30am CDT, 6:30-8:30am PDT, 2:30-4:30pm UK, 10:30pm-12:30am JST However, we will have 5-7pm Thursday call (this week only) since topic owners, Andrew and Jem, are available only evening time on this Thursday. ATTENTION: Dial-in numbers for this Thursday: US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: <MMDD> See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (if available) Action Items status review (see the bottom of this email) Agenda bashing 2) OGSA webcast slide review (100 min, Jem and Andrew) Jem will send out revised slide 24H before the call. Current slides are available at: https://forge.gridforum.org/projects/ogsa-wg/document/OGSA_Webcast_slides_d… OGSA webcast (April 26 Wed 2-3:30pm EDT) slide review. 3) Wrap up AOB <*NEXT CALL*> April 13 (Thu) April 17 (Mon) HPC profile (Marvin), OGSA webcast dry run? (Jem and Andrew) April 20 (Thu) EMS scenarios (Steven) Joint CDDLM session (Dejan and Jun) April 24 (Mon) Information Model (Fred and Ellen) Security (Frank) April 26 (Wed, 2-3:30pm EDT) OGSA webcast on air April 27 (Thu) GGF17 preparation May 1, 4, 8 NO call GGF17 May 10-12 in Tokyo Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ <*ACTION ITEMS*> From April 10 telecon - Hiro: to ask Marvin if we can add webcast dry run to April 17 call. From April 5 pm F2F meeting - Webcast Participants: send bios to Jem. - Frank: to inform Jem about his availability for webcast on air Other - Tom: to finalize OGSA WSRF BP 1.0 doc and make a final call -- Hiro Kishimoto

2 1

RE: [ogsa-wg] Webcast slides updated
by Fred Maciel 13 Apr '06

13 Apr '06

Hi, Here is a shooting target for the resource management slide. See ya, Fred Maciel Hitachi America R&D

1 0

RE: GGF/OGSA standards for hierarchical namespaces
by Christopher Jordan 12 Apr '06

12 Apr '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (I don't seem to have any record of minutes having been taken or sent out for this session - if I'm wrong or just missed an e-mail in the endless shuffle of my inbox, feel free to correct me, but this document may be taken as a poor-man's minutes, rambling, incoherent, and just plain wrong though it may be in parts - I was calling in and so wasn't always able to catch all of the discussion.) First, I'd like to again thank all the participants in the e-mail and the F2F discussions for helping us to move this forward. Regarding the F2F Naming session, I think the RNS/WS-Directory portion was a very productive discussion, and it certainly seemed to me that there is general agreement on the need for a refactored or decomposed version of RNS, as well as agreement on the general components that will be required. I will refer to the portion of the re-factored RNS that provides the POSIX directory-like functionality RNS-Directory, for lack of a better term at this point. In fact, the sense I got was that not only is it generally agreed that this type of thing is needed, but that it is needed as soon as possible; I certainly feel this way, since much of the work of the GFS-WG should ideally consist of the definition of a "profile" for GFS usage of RNS- Directory. Mark Morgan made it abundantly clear that WS-Directory is not currently being offered as a proposed GGF standard document, but is merely intended to provide a somewhat simpler, and in fact quite minimal, example of a hierarchically structured set of human-readable names which are associated with XML documents containing at least an EPR and, as of the most recent version, arbitrary XML, as the entry document definition includes an "{xsd:any} *" component. I, for one, feel that WS-Directory will be a a valuable reference point in the development of the directory service component of RNS 2.0, or whatever it ends up being called. Initial action items coming out of the discussion were that Mark Morgan and Manuel Pereira were to do some communication to try and get synchronized on at least some initial ideas about what might need to come out of RNS and how it might need to be changed in order to get to this magical future invention I call RNS-Directory. I've offered to help in whatever capacity I can, including arranging for mailing lists and conference calls if necessary, in addition to offering my opinions, which by this point is probably assumed ;-). My personal feeling was that the most difficult issue to resolve was the question of where the re-factoring effort should live and how it should proceed; , but it seemed to be generally agreed that GFS-WG is too far down the GGF hierarchy to be responsible for something that, as someone put it most appropriately (sorry for not recognizing your voice), needs the level of visibility associated with being at the OGSA-* level. At the same time, Mark Morgan suggested that perhaps OGSA-Naming wasn't necessarily a perfect fit for this effort, as there isn't quite the right overlap with the efforts and individuals currently in OGSA-Naming. The last suggestion I heard clearly in toto was that it should be "officially" part of OGSA-Naming, but that it may need separate conference calls, GGF sessions, and other devices to maintain at least some separation from the mainstream OGSA-Naming work. Manuel explained to me, as a relative newcomer, the original agreement that the GFS-WG would be responsible for development of RNS, and that OGSA-Naming would then take over maintenance of it once it had become a GFD, and something like this still seems like a good idea, as long as we can maintain the required level of visibility. I'd appreciate it if someone who was there could let us all know what, if any, final decisions were made regarding how this process will proceed. I haven't had a chance to look at WS-Enumeration, but it's on my reading list - at the least, it should be useful in thinking about how to integrate the directory work with separate and more generally applicable iteration or enumeration standards. Thanks, On Apr 5, 2006, at 12:53 PM, Dave Berry wrote: > Hi Chris, > > Thanks for this note. I hope the F2F discussion is productive. > > I will repeat my suggestion that the naming team should look at > WS-Enumeration to see if it, or an extension thereof, satisfies the > requirements for an iteration interface. I have no idea whether it > does > meet those requirements but we should take a look. This is especially > true given the MS/IBM/HP/Intel WS white paper, which has WS- > Enumeration > in at the bottom layer. > > Another question I've had raised to me is whether we can use WSRF/WSRT > to handle the properties associated with entries in the directory. I > personally don't see how this would work, but given the context we're > working in it would be helpful to establish what relationship > exists, if > any. > > Best wishes, > > Dave. > - ---------------------------------------------------- Chris Jordan HPC Systems Engineer High End Computing Systems Group San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEOL5nPCVtcXn6kg8RAvUhAJoD9nu2O8c2sxUzDbFDkD0lrFziRQCeIqcX 8HpYq17rM4OSxlCXLV/VNFQ= =uKze -----END PGP SIGNATURE-----

2 1

Re: GGF/OGSA standards for hierarchical namespaces
by Christopher Jordan 12 Apr '06

12 Apr '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, I think I was trying to say something along those lines, but you stated it much more clearly than I did. In addition, I completely agree with you in regard to both the importance of RNS/Directory services to OGSA-Naming and the fact that GFS is a more appropriate forum for the refactoring work to be completed. (I assume you mean "OGSA-Naming" below instead of "WS-Naming") I think it's extremely important that this work not just end up being done by Manuel and Mark for lack of an agreed-upon forum and process; not that they aren't perfectly capable, but we do have GGF and five thousand working groups around for a reason... As I said previously, if there was a final decision made at the F2F on which forum to use to do this, I missed it. My own suggestion is that we stick with the original plan, i.e. finish the development process in GFS, which of course will be more than willing to accept participation from interested parties, then hand it off to OGSA-Naming. How do we reach "official" consensus on this? Or did we do so already, and I just didn't hear it over the phone? On Apr 9, 2006, at 8:16 AM, Mark Morgan wrote: > Chris, > > Thanks for your input and assessment of the situation. I believe > you are > correct but I did want to make one small clarification (and please > forgive > me if I am re-stating something already said in this email -- it's > early and > I'm still jet-lagged). It isn't that I think that hierarchical naming > doesn't belong in WS-Naming. In fact, it's VERY important there. > However, > I don't think that re-factoring RNS as an activity belongs in WS- > Naming. > WS-Naming should help with this, but I definitely believe that the > re-factoring effort needs to take place in GFS where the goals and > beliefs > of the original authors can best find voice. If this makes any sense! > > -Mark > >> -----Original Message----- >> From: Christopher Jordan [mailto:ctjordan@sdsc.edu] >> Sent: Sunday, April 09, 2006 3:57 AM >> To: Dave Berry >> Cc: Ian Foster; gfs-wg(a)ggf.org; Andrew Grimshaw; Hiro >> Kishimoto; Mark Morgan; Gregory Newby; >> ogsa-naming-wg(a)ggf.org; ogsa-wg(a)ggf.org >> Subject: RE: GGF/OGSA standards for hierarchical namespaces >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> (I don't seem to have any record of minutes having been taken >> or sent out for this session - if I'm wrong or just missed an >> e-mail in the endless shuffle of my inbox, feel free to >> correct me, but this document may be taken as a poor-man's >> minutes, rambling, incoherent, and just plain wrong though it >> may be in parts - I was calling in and so wasn't always able >> to catch all of the discussion.) >> >> First, I'd like to again thank all the participants in the >> e-mail and the F2F discussions for helping us to move this forward. >> >> Regarding the F2F Naming session, I think the >> RNS/WS-Directory portion was a very productive discussion, >> and it certainly seemed to me that there is general agreement >> on the need for a refactored or decomposed version of RNS, as >> well as agreement on the general components that will be >> required. I will refer to the portion of the re-factored RNS >> that provides the POSIX directory-like functionality >> RNS-Directory, for lack of a better term at this point. In >> fact, the sense I got was that not only is it generally >> agreed that this type of thing is needed, but that it is >> needed as soon as possible; I certainly feel this way, since >> much of the work of the GFS-WG should ideally consist of the >> definition of a "profile" for GFS usage of RNS- Directory. >> >> Mark Morgan made it abundantly clear that WS-Directory is not >> currently being offered as a proposed GGF standard document, >> but is merely intended to provide a somewhat simpler, and in >> fact quite minimal, example of a hierarchically structured >> set of human-readable names which are associated with XML >> documents containing at least an EPR and, as of the most >> recent version, arbitrary XML, as the entry document >> definition includes an "{xsd:any} *" component. I, for one, >> feel that WS-Directory will be a a valuable reference point >> in the development of the directory service component of RNS >> 2.0, or whatever it ends up being called. >> >> Initial action items coming out of the discussion were that >> Mark Morgan and Manuel Pereira were to do some communication >> to try and get synchronized on at least some initial ideas >> about what might need to come out of RNS and how it might >> need to be changed in order to get to this magical future >> invention I call RNS-Directory. I've offered to help in >> whatever capacity I can, including arranging for mailing >> lists and conference calls if necessary, in addition to >> offering my opinions, which by this point is probably assumed ;-). >> >> My personal feeling was that the most difficult issue to >> resolve was the question of where the re-factoring effort >> should live and how it should proceed; , but it seemed to be >> generally agreed that GFS-WG is too far down the GGF >> hierarchy to be responsible for something that, as someone >> put it most appropriately (sorry for not recognizing your >> voice), needs the level of visibility associated with being at the >> OGSA-* level. At the same time, Mark Morgan suggested that >> perhaps OGSA-Naming wasn't necessarily a perfect fit for this >> effort, as there isn't quite the right overlap with the >> efforts and individuals currently in OGSA-Naming. The last >> suggestion I heard clearly in toto was that it should be >> "officially" part of OGSA-Naming, but that it may need >> separate conference calls, GGF sessions, and other devices to >> maintain at least some separation from the mainstream >> OGSA-Naming work. Manuel explained to me, as a relative >> newcomer, the original agreement that the GFS-WG would be >> responsible for development of RNS, and that OGSA-Naming >> would then take over maintenance of it once it had become a >> GFD, and something like this still seems like a good idea, >> as long as we can maintain the required level of visibility. >> >> I'd appreciate it if someone who was there could let us all >> know what, if any, final decisions were made regarding how >> this process will proceed. >> >> I haven't had a chance to look at WS-Enumeration, but it's on >> my reading list - at the least, it should be useful in >> thinking about how to integrate the directory work with >> separate and more generally applicable iteration or >> enumeration standards. >> >> Thanks, >> >> On Apr 5, 2006, at 12:53 PM, Dave Berry wrote: >> >>> Hi Chris, >>> >>> Thanks for this note. I hope the F2F discussion is productive. >>> >>> I will repeat my suggestion that the naming team should look at >>> WS-Enumeration to see if it, or an extension thereof, satisfies the >>> requirements for an iteration interface. I have no idea whether it >>> does meet those requirements but we should take a look. This is >>> especially true given the MS/IBM/HP/Intel WS white paper, which has >>> WS- Enumeration in at the bottom layer. >>> >>> Another question I've had raised to me is whether we can >> use WSRF/WSRT >>> to handle the properties associated with entries in the >> directory. I >>> personally don't see how this would work, but given the >> context we're >>> working in it would be helpful to establish what >> relationship exists, >>> if any. >>> >>> Best wishes, >>> >>> Dave. >>> >> >> - ---------------------------------------------------- >> Chris Jordan >> HPC Systems Engineer >> High End Computing Systems Group >> San Diego Supercomputer Center >> ctjordan(a)sdsc.edu >> 858.534.8347 >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.1 (Darwin) >> >> iD8DBQFEOL5nPCVtcXn6kg8RAvUhAJoD9nu2O8c2sxUzDbFDkD0lrFziRQCeIqcX >> 8HpYq17rM4OSxlCXLV/VNFQ= >> =uKze >> -----END PGP SIGNATURE----- >> > - ---------------------------------------------------- Chris Jordan HPC Systems Engineer High End Computing Systems Group San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEPQuUPCVtcXn6kg8RAowjAJ4nFZOnEMnrOY1pzbNpnKhGWsW+owCgiscr AzFY50zRmN3nexUNt+Rlfwo= =qBFr -----END PGP SIGNATURE-----

1 0

Proposed agenda for April 10th call
by Hiro Kishimoto 11 Apr '06

11 Apr '06

Hi all, Thank you very much for all of you who came to F2F meeting. We had very lively and productive meetings including CDDLM, HPC profile, Info Model, naming, webcast and others. ATTENTION: From April 10th and onward, weekly telecon day/time will change as following; - Monday: 6-8pm EDT, 5-7pm CDT, 3-6pm PDT, 11pm-1am UK, 7-9am JST - Thursday: 9:30-10:30am EDT, 8:30-10:30am CDT, 6:30-8:30am PDT, 2:30-4:30pm UK, 10:30pm-12:30am JST Also, in order to improve the productivity, the following guideline is agreed at the F2F meeting. - Proposed agenda will be posted at least 48 hours in advance. - Meeting materials will be posted either mailing list or gridForge at least 24 hours in advance by each topic owner. - If enough materials do not become available 24 hour deadline, WG co-chairs have authority to cancel upcoming telecon. In such cases, co-chairs notify immediately. The following is a proposed agenda for OGSA-WG telecon on April 10th Monday from 5pm to 7pm (CST). The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: <MMDD> See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (May 27) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060327 Action Items status review (see the bottom of this email) Agenda bashing 2) F2F meeting minutes approval (20 min) All meeting materials and minutes will be available in the GridForge folder. https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… 3) OGSA webcast slide review (80 min, Jem and Andrew) OGSA webcast (April 26 Wed 2-3:30pm EDT) slide review. 4) Wrap up AOB <NEXT CALL> April 13 (Thu) OGSA webcast (Jem and Andrew) April 17 (Mon) HPC profile (Marvin) April 20 (Thu) OGSA webcast dry run (Jem and Andrew), EMS scenarios (Steven) Joint CDDLM session (Dejan and Jun) April 24 (Mon) Information Model (Fred and Ellen) Security (Frank) April 26 (Wed, 2-3:30pm EDT) OGSA webcast on air April 27 (Thu) GGF17 preparation May 1, 4, 8 NO call GGF17 May 10-12 in Tokyo Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ <Action Items> From April 5 pm F2F meeting - Hiro: Ask to Steve Crumb to send advertisement to GGF list. - Webcast Participants: send bios to Jem. - Jem: Ask Andrew about his availability for webcast prep in the week of April 10 and dry run - Jem: Ask Frank about his availability for webcast on air -- Hiro Kishimoto

2 4

[ogsa-wg | Roadmap 1.1 - 1788] Definition of "implement," "conformance," and "compliance"
by Sourceforge Tracker Monitor 05 Apr '06

05 Apr '06

A new artifact has been added: 1788 Submitted by: Jem Treadwell Submitted date: 2006-04-05 18:15:19 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=815&aid=1788&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=815&aid=1788&group_id…) Summary: Definition of "implement," "conformance," and "compliance" Project: Open Grid Services Architecture Tracker: Roadmap 1.1 Artifact ID: 1788 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Jem Treadwell Last Modified: 2006-04-05 18:15:19 Submitted By: Jem Treadwell Submit Date: 2006-04-05 18:15:19 Assigned To: Jem Treadwell File(s): <None> Description: Mail received from Dave Snelling on 1/30/2006. Hiro, We should follow this up in OGSA, starting with dave B and Jem. I thought some distinction like this must exist. If Franco is right, we should probably adjust our definitions in both the OGSA and GGF roadmaps. We should track down the right legal definitions for the words just to make sure. Thoughts? Begin forwarded message: > From: "Franco Travostino" <travos(a)nortel.com> > Date: 17 January 2006 18:16:32 GMT > To: "Hiro Kishimoto" <hiro.kishimoto(a)jp.fujitsu.com>, "GFSG" > <gfsg(a)ggf.org> > Subject: Re: [gfsg] definition of "implement," "conformance," and > "compliance." > > >> 2. A claim of conformance to a specification or profile is a >> statement of intent to interoperate with other conformant >> implementations. >> Two or >> more implementations may test their conformance by testing how well >> they interoperate. A conformance claim mechanism as defined in the >> profile should be used to communicate conformance. > In this paragraph, I would use interoperability in lieu of > conformance. I'd remove the "statement of intent" and instead demand > successful execution of interoperability tests (whether these are > ad-hoc events or public bakeoffs). > >> 3. A claim of compliance would imply acceptance by a set of OGSA >> Compliance Tests. At the time of writing no such tests exist. >> We may expect that OGSA compliance tests will be developed that >> define the practical criteria that must be satisfied for a software >> system to be called OGSA-compliant. Until such a suite is >> available, claims of OGSA compliance should not be made. > Here, I would replace compliance with conformance (assuming that > 'conformance' is no longer used in 2). Rationale: Compliance bears the > connotation of regulatory compliance, as it applies to processes > (e.g., Sarbanes-Oxley) or complete engineering artifacts (e.g., a > car's emission gas test in my state), always implying that there are > clear, legally-binding accountabilities along the compliance process. > > -franco > > > > > At 11:21 AM 1/17/2006, Hiro Kishimoto wrote: > >> Hi all, >> >> Per request during today's GFSG standard call, I will share >> definition of "implement," "conformance," and "compliance." >> >> It is in the OGSA roadmap document (GFD.53) written by Dave Berry. >> >> 2.3 OGSA Branding >> Given the requirement for consistency across OGSA specifications and >> other documents, GGF defines in [OGSA-Related Naming Guidelines] the >> criteria to be used in determining whether to brand entities such as >> working groups and documents with an OGSA prefix. >> The OGSA normative documents are expected to be implemented by >> multiple open-source software (OSS) projects and commercial software >> vendors. >> Authors of OGSA Software may claim one of three levels of agreement >> with the OGSA normative documents: >> >> 1. A claim to implement a specification or profile is a >> statement of best effort to satisfy the requirements of the >> specification. >> There >> are no test mechanisms to guarantee the correctness of the >> implementation. >> >> 2. A claim of conformance to a specification or profile is a >> statement of intent to interoperate with other conformant >> implementations. >> Two or >> more implementations may test their conformance by testing how well >> they interoperate. A conformance claim mechanism as defined in the >> profile should be used to communicate conformance. >> >> 3. A claim of compliance would imply acceptance by a set of >> OGSA Compliance Tests. At the time of writing no such tests exist. >> We may expect that OGSA compliance tests will be developed that >> define the practical criteria that must be satisfied for a software >> system to be called OGSA-compliant. Until such a suite is >> available, claims of OGSA compliance should not be made. >> >> -- >> Hiro Kishimoto >> >> -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile) View the Roadmap 1.1 : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

Re: GGF/OGSA standards for hierarchical namespaces
by Hiro Kishimoto 05 Apr '06

05 Apr '06

Chris's email forwarding. ---- Thanks to everyone for useful responses, and to both Manuel and Mark for providing workable hierarchical, abstract naming schemes ("directory standards", in the context of this discussion), each with valuable features. I'm writing this note as a preface to the discussion of naming at the F2F meeting today, and as a response to some of the points already made in this thread. I'll mostly just be throwing out a few vaguely connected thoughts and pieces of information to help advance the starting point for the discussion today. As important as I feel it is for the community to quickly agree upon a definite direction/core draft standard, it's also crucial to get it right - we don't necessarily have to provide a perfect solution the first time, but we do have to provide a solution that can grow and change organically to fulfill new needs, as the community creates them. Just to update my previous e-mail regarding the options and suggestions out there, I've spoken with Osamu Tatebe, and it appears that the RNS item in my initial list of efforts and proposals is now coincident with Dave Berry's post-GGF16 note suggesting that RNS be re-factored into at least two separate standards. In this regard, Osamu says "At the last GFS-WG session in GGF16, we agreed to refactor RNS specs into (at least) three specs; RNS, iterator, logical name resolver." It's not immediately clear to me what is meant by "RNS" in this quote, but my guess would be that it refers to the directory standard/service itself. My understanding is that Manuel Pereira is currently working on this refactoring, and will offer a draft to the GFS (and likely OGSA-Naming) working groups for further discussion, once a workable draft is complete. To clarify my own ulterior motives, my goal is to get the work on naming and directory-related issues moved into the OGSA-Naming group, even if it is the same set of players doing the work, so that the GFS- WG can focus on the requirements for file systems within a "directory and logical/abstract naming system" - for example, a GFS directory or "file" entry should have properties such as size, support information about the source storage resource and access mechanisms, replication properties, the data's tier within an HSM, etc etc. I'm hoping that we can all work together to create a set of directory naming and resolution standard(s) that can support these needs, and I believe that if we do, they will also support just about any other function for which an abstract-name-based directory system is necessary. From the above paragraph, I think it should be clear that I believe that it is a requirement to be the able to associate arbitrary attributes/properties with entries in the directory structure. What I envision here is a simple set of base standards, ideally to come out of the OGSA-Naming group; one for hierarchically organized collections of human-readable abstract names with arbitrary properties attached, each of which resolves to an EPR, and one for an iterator interface, where the items being iterated over are the abstract names. Each standard utilizing hierarchical collections of human-readable names, including the GFS-WG, would then define a "profile" for use of the directory service, including requirements for the properties which should be associated with a directory entry, and any higher-level services which would ideally build upon the "directory" standard I'm hoping to see. I believe that the WS-Directory proposal, certainly in the v3 iteration Mark Morgan referred us to in an earlier e-mail, would fulfill the requirements I have for hierarchically organized collections of human-readable names, referring to EPRs and having attributes associated with them. We still need, in my opinion, an iterator interface standard to work in concert with these "directories"; hopefully Manuel's work with refactoring RNS will provide us with that. I'll stop here, since I believe the F2F discussion of naming will begin shortly. Thanks again to everyone for participating in this discussion so far, and I look forward to continuing it both in the F2F and through other channels. On Mar 28, 2006, at 11:17 AM, Allen Luniewski wrote: > > Chris, > > Thanks for the very thoughtful note! A few comments. > > I agree with you that the current situation is, to put it mildly, > not acceptable. We need to move to a position where the community > agrees on a single means for creating a hierarchy of pointers to > resources (a directory structure in Unix-speak). Clearly one > aspect of this is that RNS and WS-Directory need to reconciled into > a single proposal. Resolution sooner rather than later is clearly > in the best interests of the various WGs who depend upon > directories (including OGSA Data which I share responsibility for). > > You mention a couple of specific technical issues. A few comments > on those: > 1. I go back and forth on attributes in the directory > system. Since these are almost certainly cached from the > resources, today I am inclined to say that > attributes should not be part of the directory > system. Ask me tomorrow, and I may have the other answer :-) But > today, I would leave them out > of the base specification for simplicity but > consider an extension that included attributes if that were felt to > be vital. > 2. Dave Berry's suggestion to separate out the iterator > component is a good one. There are going to be many places in the > overall grid standards > effort where an iterator-like structure will be > needed. Standardizing this seems like a proper goal for GGF. If > that is accepted then using it > in a directory service seems quite natural. > > As for moving forward, I think that we need to see how this thread > plays out. My instincts, however, are that getting the interested > parties in a room for a few hours would be the most effective way > to drive this to an early resolution. > > Allen Luniewski > IBM Information Management Division > San Jose, California > > > > Christopher Jordan <ctjordan(a)sdsc.edu> > Subject: GGF/OGSA standards for hierarchical namespaces > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > All, > > Forgive the wide distribution on this e-mail, but this issue seems to > be to be both extraordinarily important to the future of GGF/OGSA > standards efforts and also in a state of either limbo or paralysis. > The topic I'm addressing here, both in my capacity as the secretary > of GFS-WG and as a generally interested participant on a few > different GGF working groups, is the question of adopting a single, > possibly minimal, standard for creating hierarchically organized > collections of pointers (WS-Names? GSR/GSHs, to date myself?) to > "resources", where the term "resource" could denote a service > providing access to a collection of files, computational resources, > or database records (that's a non-exclusive list), and where some > items in the hierarchy could actually represent directory-like > structures, i.e. containers for other collections of resources. > > The way I got involved in this discussion through the Grid File > Systems-WG, which at the time was bringing the RNS specification > forward for final approval as a GFD. Subsequently, there have been > numerous discussions outside of the GFS-WG context about the > suitability of the RNS standard for more general applications, as > well as the (perceived) complexity of the standard as a barrier to > entry. There have also been alternative directory construction > standards proposed by members of the OGSA-Naming-WG. > > The following are the activities/proposals I know of: > > RNS: I know the GGF editors have returned the final(?) RNS draft to > GFS-WG, with the suggestion that it is too specific to filesystem > needs, and the suggestion that it either be limited in scope to GFS > applications only (a non-optimal solution for obvious reasons) or > that the authors work with the OGSA-Naming people to help develop a > universal standard for hierarchical resource namespaces. If we are to > move forward with RNS, one of these options will clearly be a > necessity, given the points Greg Newby made in his responses on > behalf of the GFSG. > > WS-Directory: This is the hierarchical namespace standard developed > at UVa in response to their difficulty in implementing the > complexities and ambiguities in RNS. I like the simplicity of WS- > Directory, however it seems to be missing significant requirements > for general use such as attributes, both attributed which should be > required such as time-to-live, and the ability to add extensibility > attributes such as resource type, QoS, etc. This ability to add > arbitrary attributes is present in RNS but it still lacks some > obviously fundamental required attributes. > > Finally, Dave Berry sent an e-mail immediately after GGF16 in which > he mentioned the suggestion that we separate this functionality into > two logical functions, and therefore standards - a Directory > Interface and an Iterator interface, in which Directory interfaces > were essentially just pointers to Iterators, which would be > standardized. However, there would be no restriction that a Directory > point to a particular type of iterator interface. One point I wasn't > clear on from the e-mail was whether an entry in an interator could > be another directory, although I suspect it can. > > This short list is what I've got within easy reach. As I said > previously, I believe this is an important issue to resolve quickly, > and I'm sending this note in the hopes of initiating the conversation > among as many of the relevant parties as I can. Please feel free to > forward at will, respond with agreement, anger, or even unconcealed > rage. > > Possible ways forward would be for us to have a conference call (GFS- > WG meets rarely, and we could quite easily give up our call for a > more focused discussion of these issues), an extended e-mail > discussion, or a meeting at the next GGF (assuming we get a chance). > > Let me know how you feel about the options presented above, or feel > free to propose new ones if you like. The important thing is that we > begin to gain momentum, and then keep it going forward. > > Thanks. > > N.B. For anyone who may have missed any of the discussions reference > above, please let me know and I'll be happy to forward them to you > from my archives. - ---------------------------------------------------- Chris Jordan HPC Systems Engineer High End Computing Systems Group San Diego Supercomputer Center ctjordan(a)sdsc.edu 858.534.8347 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEM/xVPCVtcXn6kg8RArY1AKCO4lAdeWchGcMgDcmDl1YAx5jEQwCgybp7 NZUrUXmTwpseVL9P0/WscUI= =AhSs -----END PGP SIGNATURE-----

1 0

Missed commitments
by Andrew Grimshaw 05 Apr '06

05 Apr '06

All, This is a mass mailing because I am not sure how many people I told "I'll get you X by Y". I have been sick for the last ten to twelve days. While I came in to teach - my head was not there. Focus has been a problem. So, after many drugs, tubes, and 12-18/hrs a day of sleep I am finally out of what ever it was. If I have dropped the ball on something I said I would do, please send me a gentle reminder and I will get to it. Ps. For you youngsters - this was the first time I ever felt I was sick and my body simply would not through it off in a few days. I am told I can expect more of those sorts of experiences as the machine's components fail. Something to look forward to. A Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

1 0

Draft Execution Service Interface Specification
by David Snelling 04 Apr '06

04 Apr '06

Folks, With my Unicore hat on, I have been working with some of the Globus people to see if we (Unicore and Globus) can agree on a joint Job submit and management interface specification. The progress has been very good, but we are by no means finished. However, the spec is mature enough to open it for your input. Ian and I are acting as editors, so please send issues and comments at least to us. To put this work in the current OGSA context, I see this specification as the WSRF OGSA Base Profile rendering of a fairly complete execution service interface. I don't believe it is much more complicated than the minimal set of capabilities needed to address the HPC use cases posted by Marvin. This might therefore also be the WSRF BP rendering of that as well (given suitable optionality at strategic places) , but more analysis is needed. With respect to the OGSA-BES work, we see this as a possible next step for BES-like services. The corresponding factory operation in this specification is slightly more complex than the BES create activity operation, but is not intended to replace it. I realize that the schema and WSDL sections are missing. I assure you that drafts of these exist, but are grossly out of phase with the main document. We will be working over the coming weeks to develop these. Let us know what you think. I plan to join the EMS discussion tomorrow by phone and can answer questions then if people have them. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

1 0

Meeting material for OGSA-WG general session
by Hiro Kishimoto 04 Apr '06

04 Apr '06

Hi all, I've upload meeting material for OGSA-WG general session to gridForge meeting folder. https://forge.gridforum.org/projects/ogsa-wg/document/20060404am_F2F_slide_… See you tomorrow, -- Hiro Kishimoto

1 0

New version of the guidelines document -- please review for F2F
by Fred Maciel 03 Apr '06

03 Apr '06

Hi, I just finished a new version of the guidelines document to be reviewed in the face-to-face. Apologies for the delay. Most changes from the last version are shown in the document, but I'm not showing changes such as re-ordering of sections. I addressed all the feedback from the last revision in the March 8 teleconference. This version also includes lots of changes and comments from Jem (Jem: many thanks. BTW I erased the comments which I reflected in the text). I also changed the format to reflect the contents of the new GGF template. As usual, the latest version is at the URL below. https://forge.gridforum.org/projects/ogsa-wg/document/Modeling_Guideline s/en I've also uploaded that version to the F2F folder: Regards, Fred Maciel Hitachi America R&D

2 1

[ogsa-wg | Roadmap 1.1 - 1785] Ref to WSRF Basic Profile missing in v1.0
by Sourceforge Tracker Monitor 03 Apr '06

03 Apr '06

A new artifact has been added: 1785 Submitted by: Jem Treadwell Submitted date: 2006-04-03 12:04:30 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=815&aid=1785&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=815&aid=1785&group_id…) Summary: Ref to WSRF Basic Profile missing in v1.0 Project: Open Grid Services Architecture Tracker: Roadmap 1.1 Artifact ID: 1785 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Jem Treadwell Last Modified: 2006-04-03 12:04:30 Submitted By: Jem Treadwell Submit Date: 2006-04-03 12:04:30 Assigned To: Jem Treadwell File(s): <None> Description: Reported by Morris Riedel [mailto:m.riedel@fz-juelich.de] 4/3/2006. In the Roadmap v1.0 on pages 5, 10 & 11 there are references to [OGSA WSRF Basic Profile], but the reference is missing. This shows up as a broken reference in the PDF version. View the Roadmap 1.1 : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

No call on Monday
by Hiro Kishimoto 02 Apr '06

02 Apr '06

Hi all, Since we will have F2F meeting from Tuesday to Friday, we have NO telecon in next week. We will discuss telecon timeslot at the F2F meeting and likely to change from April 10 onward. Have a safe trip and see you in Sunnyvale. -- Hiro Kishimoto

1 0

Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Carl Kesselman 02 Apr '06

02 Apr '06

Hi, In the interest of furthering agreement, I was not arguing that the application had to be restartable. Rather, what has been shown to be important is that the protocol be restartable in the following sense: if you submit a job and the far and server fails, is the job running or not, if you resubmit, do you get another job instance. The GT sumbission protocol and Condor have a transactional semantics so that you can have at most once submit semantics reegardless of client and server failures. The fact that your application may be non-itempote is exactly why having a well defined semantics in this case is important. So what is the next step? Carl Dr. Carl Kesselman email: carl(a)isi.edu USC/Information Sciences Institute WWW: http://www.isi.edu/~carl 4676 Admiralty Way, Suite 1001 Phone: (310) 448-9338 Marina del Rey, CA 90292-6695 Fax: (310) 823-6714 -----Original Message----- From: Marvin Theimer <theimer(a)microsoft.com> To: Carl Kesselman <carl(a)isi.edu> CC: Marvin Theimer <theimer(a)microsoft.com>; Marty Humphrey <humphrey(a)cs.virginia.edu>; ogsa-wg(a)ggf.org <ogsa-wg(a)ggf.org> Sent: Wed Mar 15 14:26:36 2006 Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Hi; I suspect that we're mostly in agreement on things. In particular, I think your list of four core aspects is a great starting point for a discussion on the topic. I just replied to an earlier email from Ravi with a description of what I'm hoping to get out of examining various HPC use cases: · Identification of the simplest base case that everyone will have to implement. · Identification of common cases we want to optimize. · Identification of how evolution and selective extension will work. I totally agree with you that the base use case I described isn't really a "grid" use case. But it is an HPC use case - in fact it is arguably the most common use case in current existence. J So I think it's important that we understand how to seamlessly integrate and support that common - and very simple - use case. I also totally agree with you that we can't let a solution to the simplest HPC use case paint us into a corner that prevents supporting the richer use cases that grid computing is all about. That's why I'd like to spend significant effort exploring and understanding the issues of how to support evolution and selective extension. In an ideal world a legacy compute cluster job scheduler could have a simple "grid shim" that let it participate at a basic level, in a natural manner, in a grid environment, while smarter clients and HPC services could interoperate with each other in various selectively richer manners by means of extensions to the basic HPC grid design. One place where I disagree with you is your assertion that everything needs to be designed to be restartable. While that's a good goal to pursue I'm not convinced that you can achieve it in all cases. In particular, there are at least two cases that I claim we want to support that aren't restartable: · We want to be able to run applications that aren't restartable; for example, because they perform non-idempotent operations on the external physical environment. If such an application fails during execution then the only one who can figure out what the proper next steps are is the end user. · We want to be able to include (often-times legacy) systems that aren't fault tolerant, such as simple small compute clusters where the owners didn't think that fault tolerance was worth paying for. Of course any acceptable design will have to enable systems that are fault tolerant to export/expose that capability. To my mind it's more a matter of ensuring that non-fault-tolerant systems aren't excluded from participation in a grid. Other things we agree on: · We should certainly examine what remote job submission systems do. We should certainly look at existing systems like Globus, Unicore, and Legion. In general, we should be looking at everything that has any actual experience that we can learn from and everything that is actually deployed and hence represents a system that we potentially need to interoperate with. (Whether a final design is actually able to interoperate at any but the most basic level with various exotic existing systems is a separate issue.) · We should absolutely focus on codifying what we know how to do and avoid doing research as part of a standards process. I believe that thinking carefully about how to support evolution and extension is our best hope for allowing people to defer trying to bake their pet research topic into standards since it provides a story for why today's standards don't preclude tomorrow's improvements. So I would propose that next steps are: · Continue to explore and classify various HPC use cases of various differing levels of complexity. · Describe the requirements - and limitations - of existing job scheduling and remote job submission systems. · Continue identifying and discussing key "features" of use cases and potential design solutions, such as the four that you identified in your last email. Marvin. ________________________________ From: Carl Kesselman [mailto:carl@isi.edu] Sent: Tuesday, March 14, 2006 7:50 AM To: Marty Humphrey; ogsa-wg(a)ggf.org Cc: Marvin Theimer Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Hi, Just to be clear, I'm not trying to suggest that the scope be expanded. I agree with the approach of focusing on a baby step is a good one, and many of the assumptions stated in Marvin's list I am in total agreement with. However, in taking baby steps I think that it is important that we end up walking, and that in defining the use case, one can easily create solutions that will not get you to the next step. This is my point about looking at what we know how to do and have been doing in production settings for many years now. In my mind, one of the scope grandness problems has been that there has been far too little focus on codifying what we know how to do in favor of using a standards process as an excuse to design new things. So at the risk of sounding partisan, the simplified use case that Marvin is proposing is exactly the use case that GRAM has been doing for over ten years now (I think the same can be said about UNICORE and Legion). So let me try to be constructive. One of the things that falls out of Marvin's list could be a set of basic concepts/operations that need to be defined. These include: 1) A way of describing "local" job configuration, i.e. where to find the executable, data files, etc. This should be very conservative with its assumptions on shared file systems and accessibility. In general, what needs to be stated here are what are the underlying aspects of the underlying resource that are exposed to the outward facing interface. 2) A way of naming a submission point (should probably have a way of modeling queues). 3) A core set of job management operations, submit, status, kill. These need to be defined in such a way at to be tolerate to a variety of failure scenarios, in that the state needs to be well defined in the case of failure. 4) A state model that one can use to describe what is going on with the jobs and a way to access that state. Can be simple (queued, running, done), may need to be extensible. One can view the accounting information as being exposed So, one thing to do would be to agree that these are (or are not) the right four things that need to be defined and if so, start to flesh out these in a way that supports the core use case but doesn't introduce assumptions that would preclude more complex use cases in the future. Carl ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marty Humphrey Sent: Tuesday, March 14, 2006 6:32 AM To: ogsa-wg(a)ggf.org Cc: 'Marvin Theimer' Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Carl, Your comments are very important. We would love to have your active participation in this effort. Your experience is, of course, matched by few! I re-emphasize that this represents (my words, not anyone else's) "baby steps" that are necessary and important for the Grid community. In my opinion, the biggest challenge will be to fight the urge to expand the scope beyond a small size. You cannot ignore the possibility that the GGF has NOT made as much progress as it should have to date. Furthermore, one such plausible explanation is that the scope is too grand. -- Marty ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Carl Kesselman Sent: Tuesday, March 14, 2006 8:47 AM To: Marvin Theimer; Ian Foster; ogsa-wg(a)ggf.org Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Hi, While I have no wish to engage in the "what is a Grid" argument, there are some elements of your base use case that I would be concerned about. Specifically, the assumption that the submission in into a "local cluster" on which there is an existing account may lead one to a solution that may not generalize to the solution to the case of submission across autonomous policy domains. I would also argue that ignoring issues of fault tolerance from the beginning is also problematic. One must at least design operations that are restartable (for example at most once submission semantics). I would finally suggest that while examining existing job schedule systems is a good thing to do, we should also examine existing remote submission systems (dare I say Grid systems). The basic HPC use case is one in which there is a significant amount implementation and usage experience. Thanks, Carl ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marvin Theimer Sent: Monday, March 13, 2006 2:42 PM To: Ian Foster; ogsa-wg(a)ggf.org Cc: Marvin Theimer Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Hi; Ian, you are correct that I view job submission to a cluster as being one of the simplest, and hence most basic, HPC use cases to start with. Or, to be slightly more general, I view job submission to a "black box" that can run jobs - be it a cluster or an SMP or an SGI NUMA machine or what-have-you - as being the simplest and hence most basic HPC use case to start with. The key distinction for me is that the internals of the "box" are for the most part not visible to the client, at least as far as submitting and running compute jobs is concerned. There may well be a separate interface for dealing with things like system management, but I want to explicitly separate those things out in order to allow for use of "boxes" that might be managed by proprietary means or by means obeying standards that a particular job submission client is unfamiliar with. I think the use case that Ravi Subramaniam posted to this mailing list back on 2/17 is a good one to start a discussion around. However, I'd like to present it from a different point-of-view than he did. The manner in which the use case is currently presented emphasizes all the capabilities and services needed to handle the fully general case of submitting a batch job to a computing utility/service. That's a great way of producing a taxonomy against which any given system or design can be compared to see what it has to offer. I would argue that the next step is to ask what's the simplest subset that represents a useful system/design and how should one categorize the various capabilities and services he has identified so as to arrive at meaningful components that can be selectively used to obtain progressively more capable systems. Another useful exercise to do is to examine existing job scheduling systems in order to understand what they provide. Since in the real world we will have to deal with the legacy of existing systems it will be important to understand how they relate to the use cases we explore. In the same vein, it will be important to take into account and understand other existing infrastructures that people use that are related to HPC use cases. I'm thinking of things like security infrastructures, directory services, and so forth. From the point-of-view of managing complexity and reducing total-cost-of-ownership, it will be important to understand the extent to which existing infrastructure and services can be reused rather than reinvented. To kick off a discussion around the topic of a minimalist HPC use case, I present a straw man description of such below and then present a first attempt at categorizing various areas of extension. The categorization of extension areas is not meant to be complete or even all that carefully thought-out as far as componentization boundaries are concerned; it is merely meant to be a first contribution to get the discussion going. A basic HPC use case: Compute cluster embedded within an organization. · This is your basic batch job scheduling scenario. Only a very basic state transition diagram is visible to the client, with the following states for a job: queued, running, finished. Additional states -- and associated state transition request operations and functionality -- are not supported. Examples of additional states and associated functionality include suspension of jobs and migration of jobs. · Only "standard" resources can be described, for example: number of cpus/nodes needed, memory requirements, disk requirements, etc. (think resources that are describable by JSDL). · Once a job has been submitted it can be cancelled, but its resource requests can't be modified. · A distributed file system is accessible from client desktop machines and client file servers, as well as compute nodes of the compute cluster. This implies that no data staging is required, that programs can be (for the most part) executed from existing file system locations, and that no program "provisioning" is required (since you can execute them from wherever they are already installed). Thus in this use case all data transfer and program installation operations are the responsibility of the user. · Users already have accounts within the existing security infrastructure (e.g. Kerberos). They would like to use these and not have to create/manage additional authentication/authorization credentials (at least at the level that is visible to them). · The job scheduling service resides at a well-known network name and it is aware of the compute cluster and its resources by "private" means (e.g. it runs on the head node of the cluster and employs private means to monitor and control the resources of the cluster). This implies that there is no need for any sort of directory services for finding the compute cluster or the resources it represents other than basic DNS. · Compute cluster system management is opaque to users and is the concern of the compute cluster's owners. This implies that system management is not part of the compute cluster's public job scheduling interface. This also implies that there is no need for a logging interface to the service. I assume that application-level logging can be done by means of libraries that write to client files; i.e. that there is no need for any sort of special system support for logging. · A simple polling-based interface is the simplest form of interface to something like a job scheduling service. However, a simple call-back notification interface is a very useful addition that potentially provides substantial performance benefits since it can enable the avoidance of lots of unnecessary network traffic. Only job state changes result in notification messages. · There are no notions of fault tolerance. Jobs that fail must be resubmitted by the client. Neither the cluster head node nor its compute nodes are fault tolerant. I do expect the client software to return an indication of failure-due-system-fault when appropriate. (Note that this may also occur when things like network partitions occur.) · One does need some notion of how to deal with orphaned resources and jobs. The notion of job lifetime and post-expiration garbage collection is a natural approach here. · The scheduling service provides a fixed set of scheduling policies, with only a few basic choices (or maybe even just one), such as FIFO or round-robin. There is no notion, in general, of SLAs (which are a form of scheduling policy). · Enough information must be returned to the client when a job finishes to enable basic accounting functionality. This means things like total wall-clock time the job ran and a summary of resources used. There is not a need for the interface to support any sort of grouping of accounting information. That is, jobs do not need to be associated with projects, groups, or other accounting entities and the job scheduling service is not responsible for tracking accounting information across such entities. As long as basic resource utilization information is returnable for each job, accounting can be done externally to the job scheduling service. I do assume that jobs can be uniquely identified by some means and can be uniquely associated with some principal entity existing in the overall system, such as a user name. · Just as there is no notion of requiring the job scheduling service to track any but the most basic job-level accounting information, there is no notion of the service enforcing quotas on jobs. · Although it is generally useful to separate the notions of resource reservation from resource usage (e.g. to enable interactive and debugging use of resources), it is not a necessity for the most basic of job scheduling services. · There is no notion of tying multiple jobs together, either to support things like dependency graphs or to support things like workflows. Such capabilities must be implemented by clients of the job scheduling service. Interesting extension areas: · Additional scheduling policies o Weighted fair-share, ... o Multiple queues o SLAs o ... · Extended resource descriptions o Additional resource types, such as GPUs o Additional types of compute resources, such as desktop computers o Condor-style class ads · Extended job descriptions (as returned to requesting clients and sys admins) · Additional classes of security credentials · Reservations separated from execution o Enabling interactive and debugging jobs o Support for multiple competing schedulers (incl. desktop cycle stealing and market-based approaches to scheduling compute resources) · Ability to modify jobs during their existence · Fault tolerance o Automatic rescheduling of jobs that failed due to system faults o Highly available resources: This is partly a policy statement by a scheduling service about its characteristics and partly the ability to rebind clients to migrated service endpoints · Extended state transition diagrams and associated functionalities o Job suspension o Job migration o ... · Accounting & quotas · Operating on arrays of jobs · Meta-schedulers, multiple schedulers, and ecologies and hierarchies of multiple schedulers o Meta-schedulers · Hierarchical job scheduling with a meta-scheduler as the only entry point; forwarding jobs to the meta-scheduler from other subsidiary schedulers o Condor-style matchmaking · Directory services o Using existing directory services o Abstract directory service interface(s) · Data transfer topics o Application data staging · Naming · Efficiency · Convenience · Cleanup o Program staging/provisioning · Description · Installation · Cleanup Marvin. ________________________________ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Monday, February 20, 2006 9:20 AM To: Marvin Theimer; ogsa-wg(a)ggf.org Cc: Marvin Theimer; Savas Parastatidis; Tony Hey; Marty Humphrey; gcf(a)grids.ucs.indiana.edu Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Dear All: The most important thing to understand at this point (IMHO) is the scope of this "HPC use case," as this will determine just how minimal we can be. I get the impression that the principal goal may be "job submission to a cluster." Is that correct? How do we start to circumscribe the scope more explicitly? Ian. At 05:45 AM 2/16/2006 -0800, Marvin Theimer wrote: Enclosed is a paper that advocates an additional set of activities that the authors believe that the OGSA working groups should engage in. Broadly speaking, the OGSA and related working groups are already doing a bunch of important things: · There is broad exploration of the big picture, including enumeration of use cases, taxonomy of areas, identification of research issues, etc. · There is work going on in each of the horizontal areas that have been identified, such as EMS, data services, etc. · There is working going around individual specifications, such as BES, JSDL, etc. Given that individual specifications are beginning to come to fruition, the authors believe it is time to also start defining vertical profilesthat precisely describe how groups of individual specifications should be employed to implement specific use cases in an interoperable manner. The authors also believe that the process of defining these profiles offers an opportunity to close the design loopby relating the various on-going protocol and standards efforts back to the use cases in a very concrete manner. This provides an end-to-end setting in which to identify holes and issues that might require additional protocols and/or (incremental) changes to existing protocols. The paper introduces both the general notion of doing focused vertical design effortsand then focuses on a specific vertical design effort, namely a minimal HPC design. The paper derives a specific HPC design in a first principlesmanner since the authors believe that this increases the chances of identifying issues. As a consequence, existing specifications and the activities of existing working groups are not mentioned and this paper is not an attempt to actually define a specifications profile. Also, the absence of references to existing work is not meant to imply that such work is in any way irrelevant or inappropriate. The paper should be viewed as a first abstract attempt to propose a new kind of activity within OGSA. The expectation is that future open discussions and publications will explore the concrete details of such a proposal. This paper was recently sent to a few key individuals in order to get feedback from them before submitting it to the wider GGF community. Unfortunately that process took longer than intended and some members of the community may have already seen a copy of the paper without knowing the context within it was written. This email should hopefully dispel any misconceptions that may have occurred. For those people who will be around on for the F2F meetings on Friday, Marvin Theimer will be giving a talk on the contents of this paper at a time and place to be announced. Marvin Theimer, Savas Parastatidis, Tony Hey, Marty Humphrey, Geoffrey Fox _______________________________________________________________ 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 <http://www.globus.org/>

7 16

Minutes for Monday 3/27 telecon
by Treadwell, Jem 30 Mar '06

30 Mar '06

Hi, The minutes are attached. They are *not* yet uploaded, as I don't seem to be able to do it, but I won't be able to do it today as I'm in class all day (and running late), so Hiro/Andreas if you can upload them please go ahead - thanks! - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com>

2 1

Proposed Telecon Timeslot
by Hiro Kishimoto 29 Mar '06

29 Mar '06

Hi all, Daylight Saving Time has already started this week in Europe and will start this weekend in US. The least painful timeslot was discussed at Monday call and the following *new* timeslot was proposed. Two different timeslots for distributing a burden and maybe distributing a topics and attendees. - Mon: 6:00pm Eastern, 11:00pm UK, 7:00am (Tuesday) Japan - Thu: 9:30am Eastern, 2:30pm UK, 10:30pm Japan If you have better idea, please let me know. We will review this proposal again at F2F meeting next week and will use them from April 10 and onward. See attached table. Thanks, -- Hiro Kishimoto

1 0

Proposed agenda for March 29th call
by Hiro Kishimoto 29 Mar '06

29 Mar '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 29th. Wednesday from 4pm to 6pm (CST). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0329 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (if available) Agenda bashing 2) April F2F meeting update (10 min) Revised meeting agenda is on GridForge: https://forge.gridforum.org/projects/ogsa-wg/document/2006Apr-OGSA-F2F-agen… 3) Security Architecture discussion (30 min) Scope, goal, and process discussion. 4) Information model discussion (30 min) Ellen will send out revised container info model (CIM profile) draft for review. 5) Joint CDDLM discussion (30 min) we will review Jun's CDL example document for BLAST job. Jun: Please send out CDL example document before the call. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-2006-03-15/en… 6) Wrap up AOB <NEXT CALL> April 3 (Mon): NO call April 4-7: F2F meeting in San Francisco Bay Area Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

3 2

RE: [ogsa-wg] Webcast thoughts (abstract)
by Treadwell, Jem 27 Mar '06

27 Mar '06

Hi, Attached is an updated version of the abstract with mods from Mike Behrens. The agenda for tonight's call is fairly full, but I need to submit it tomorrow, so I'd like to squeeze in a *brief* discussion to finalize it, and if we can't do that we'll need to finish it off-line. Thanks! - Jem > -----Original Message----- > From: Treadwell, Jem > Sent: Monday, March 27, 2006 9:36 AM > To: 'Michael Behrens' > Subject: RE: [ogsa-wg] Webcast thoughts (abstract) > > Hi Mike, this looks great - thanks! I have one or two minor > nits, but if I don't hear anything else I'll send this out > nearer to the meeting. > > - Jem > > ________________________________ > > Jem Treadwell > Hewlett-Packard Company > 6000 Irwin Road > Mount Laurel, NJ 08054 > Phone: 856-638-6021 > Fax: 856-638-6190 > E-mail: Jem.Treadwell(a)hp.com > > > > -----Original Message----- > > From: Michael Behrens [mailto:behrens@r2ad.com] > > Sent: Saturday, March 25, 2006 11:05 AM > > To: Treadwell, Jem > > Subject: Re: [ogsa-wg] Webcast thoughts (abstract) > > > > Hey Jem, > > The abstract looks good. I did fumble around trying to re-word > > somethings, however I can't be sure that I was successful. > So, take > > it look - maybe some of the changes might be useful. > > > > Treadwell, Jem wrote: > > > > >Hi, the OGSA webcast is now confirmed for Wednesday April > > 26th. We'll > > >be discussing it on Monday's call and at the f2f in > > Sunnyvale. We plan > > >to hold a dry run on the regular con-call on Wednesday April > > 19th. It > > >will be hosted by HP; registration details to be announced. > > > > > >I need to provide an abstract and some other information, > including > > >speaker bios, by next Wednesday, 3/29, so we will need to > > finalize the > > >abstract on Monday's call. My first draft is attached - > if you have > > >comments or suggested changes please mark them up on the > > document and > > >return them to me as soon as possible, so that we can > review them on > > >the call. Please don't wait until the call, as that will > inevitably > > >prolong the discussion. > > > > > >Thanks! > > > > > >- Jem > > >________________________________ > > > > > >From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] > > On Behalf Of > > >Treadwell, Jem > > >Sent: Monday, March 20, 2006 1:31 PM > > >To: Andrew Grimshaw; ogsa-wg > > >Subject: RE: [ogsa-wg] Webcast thoughts > > > > > > Hi Andrew, sorry for the delayed response... for anyone > > wondering what > > >this is about, we're proposing to do a public webcast > about OGSA, in > > >the April timeframe, and will have more details once the > > logistics have > > >firmed up a little more. HP will host. > > > > > > I've been working on the slides as a background > > activity, so please > > >assume I have the pen at the moment. I agree that they need > > augmenting > > >for this. > > > > > > I think we can set our own expectations for the > > audience - we can say > > >who it's for when we advertise it. As a starting point I > assume we > > >want to pitch it in the middle - some background, but also some > > >specifics on the capabilities and where things fit. > Thoughts for an > > >outline; some of this is already in place, of course: > > > > > > * > > > Background to grid and GGF, including some > > history & definitions > > > * > > > > > > Where grid is being used now, importance in the > > commercial world, and > > >the future > > > * > > > > > > Transition to SOA & Web services - why, and > > what it means > > > * > > > Standards - why they're important, a review of > > relevant standards and > > >SDOs, including latest news > > > * Some specifics about OGSA: background, some info from > > >the Roadmap, and an explanation of profiles > > > * > > > Details of the OGSA capabilities and > > closely-related work - an intro > > >diagram and a few slides on each - high-level intro, some detailed > > >examples, status of work - we need to agree how technical > we want to > > >get, and try to keep all at the same level. e.g.: > > > > > > * > > > Infrastructure > > > * > > > Security > > > * > > > EMS > > > * > > > Data > > > * > > > Resource Mgmt > > > * > > > Info > > > * > > > CDDLM > > > * > > > Self mgmt > > > * > > > WS-Agreement > > > * > > > Naming > > > * > > > Any others? > > > > > > > > > BUT: we will have to be conscious of time: I've already > > listed too > > >much if capabilities average more than 3 minutes. So this > > is probably > > >overly ambitious. > > > > > > Although we talked earlier about a 2-hour slot, I now know it's > > >actually 90 minutes. [We'll have 30 minutes before the > > start for the > > >presenters to get online and do logistics.] So the target for the > > >presentation should be one hour, with the remainder for Q&A. > > Some time > > >will be spent on preliminaries, so Q&A will probably be down > > to 20 mins. > > >We probably won't have time to do audience polls, other than > > maybe one > > >at the end while Q&A is in progress. > > > Here are a few other things we'll need to provide ahead of time: > > > > > > * Title of presentation (e.g. "Defining the Grid: An > > >Overview of OGSA") > > > * Short abstract of session > > > * Names of speaker(s) > > > * Duration: Target one hour for presentation, 30 minutes > > >for Q&A > > > * Short bios for the speaker(s) -- two or three sentences > > >each > > > > > > > > > - Jem > > > > > >________________________________ > > > > > >Jem Treadwell > > >Hewlett-Packard Company > > >6000 Irwin Road > > >Mount Laurel, NJ 08054 > > >Phone: 856-638-6021 > > >Fax: 856-638-6190 > > >E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com> > > > > > > > > > > > >________________________________ > > > > > > From: owner-ogsa-wg(a)ggf.org > > >[mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andrew Grimshaw > > > Sent: Wednesday, March 15, 2006 10:22 AM > > > To: 'ogsa-wg' > > > Subject: [ogsa-wg] Webcast thoughts > > > > > > > > > > > > All, > > > > > > I'd like to start an email discussion in > > advance of the F2F on the > > >webcast content. While we do have an initial set of slides - > > I think we > > >need to make sure that we design the talk for our expected > > audience - > > >rather than based on the material we already have in the > deck. When > > >Dave I went to MS our slide deck was not technical enough - > > we had the > > >wrong talk with us, and so had to improvise. So, one of the > > things I'd > > >like to know is: Who is our expected audience? Is it > > technical people, > > >if so, are they web services aware?, are they applications > > developers? > > >Or are they mostly managers and planners. Or do we have to > > try and make > > >everyone happy. > > > > > > > > > > > > Any insight? > > > > > > > > > > > > A > > > > > > > > > > > > Andrew Grimshaw > > > > > > Professor of Computer Science > > > > > > University of Virginia > > > > > > 434-982-2204 > > > > > > grimshaw(a)cs.virginia.edu > > > > > > > > > > > > > > > > > > > > > > -- > > Michael Behrens > > R2AD, LLC > > (571) 594-3008 (cell) > > (703) 714-0442 (land) > > > >

1 0

Proposed agenda for March 27th call
by Hiro Kishimoto 25 Mar '06

25 Mar '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 27th Monday from 4pm to 6pm (CST). The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0327 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (March 20th) Thanks Jem. - http://tinyurl.com/nbeso Agenda bashing 2) April F2F meeting update (20 min) Fujitsu will host all 4 days Revised meeting agenda is on GridForge: https://forge.gridforum.org/projects/ogsa-wg/document/2006Apr-OGSA-F2F-agen… Session owners: Please provide detailed agenda items and upload materials to GridForge in advance. https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… 3) GGF17 session plan (10 min) OGSA-WG is requesting two workshop style session slots for GGF17. > • Steven: If we make progress on EMS at the f2f it would be good to > start exposing the use cases. A plenary-style session would be > preferable to workshop, if we can’t decide this at the f2f. Steven to > consider and discuss on Wednesday or next week. > • Fred: We could have an info model session, but prefer to wait until > the f2f to decide. May not be a priority. 4) EMS scenarios discussion (40 min) Steven will send out next scenarios text for review. 5) Information model discussion (40 min) Ellen will send out revised container info model (CIM profile) draft for review. 6) Wrap up AOB <NEXT CALL> March 29 (Wed): Security Architecture (Takuya and Frank) F2F preparation, Joint CDDLM discussion April 3 (Mon): NO call April 4-7: F2F meeting in San Francisco Bay Area Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

RE: [ogsa-wg] Webcast thoughts (abstract)
by Treadwell, Jem 24 Mar '06

24 Mar '06

Hi Ian, thanks - no argument from me. I do think we need to describe each of the capabilities, but in terms of their purpose and where they fit in the architecture, not in terms of specs. But this should be balanced with a significant amount of background info, and I agree that an objective should be to help people to understand why they should care. And as the webcast will remain available for download, we need it still to be relevant a year from now. By the way, I neglected to mention the title in the abstract document, and I'm changing my own earlier suggestion to "Defining the Grid: An Introduction to OGSA" (i.e. Introduction rather than Overview). The first part comes from the title of the Roadmap doc, which seems an appropriate theme - and of course it was also the name of a GGF16 session. We could also add something about standards, but I'm more inclined to keep it short. Other suggestions welcome. - Jem ________________________________ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Friday, March 24, 2006 12:37 PM To: Treadwell, Jem; ogsa-wg Subject: RE: [ogsa-wg] Webcast thoughts (abstract) Dear All: I'm concerned that a talk that focuses on the details of various specifications will not capture the imagination of the audience, especially as many of those specifications don't exist yet and/or have not been broadly adopted. I wonder if we should be thinking about a presentation that emphasizes more what this will let people do? Ian. At 12:21 PM 3/24/2006 -0500, Treadwell, Jem wrote: "urn:schemas-microsoft-com:office:office" xmlns:w = "urn:schemas-microsoft-com:office:word" xmlns:st1 = "urn:schemas-microsoft-com:office:smarttags"> Hi, the OGSA webcast is now confirmed for Wednesday April 26th. We'll be discussing it on Monday's call and at the f2f in Sunnyvale. We plan to hold a dry run on the regular con-call on Wednesday April 19th. It will be hosted by HP; registration details to be announced. I need to provide an abstract and some other information, including speaker bios, by next Wednesday, 3/29, so we will need to finalize the abstract on Monday's call. My first draft is attached - if you have comments or suggested changes please mark them up on the document and return them to me as soon as possible, so that we can review them on the call. Please don't wait until the call, as that will inevitably prolong the discussion. Thanks! - Jem ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Treadwell, Jem Sent: Monday, March 20, 2006 1:31 PM To: Andrew Grimshaw; ogsa-wg Subject: RE: [ogsa-wg] Webcast thoughts Hi Andrew, sorry for the delayed response... for anyone wondering what this is about, we're proposing to do a public webcast about OGSA, in the April timeframe, and will have more details once the logistics have firmed up a little more. HP will host. I've been working on the slides as a background activity, so please assume I have the pen at the moment. I agree that they need augmenting for this. I think we can set our own expectations for the audience - we can say who it's for when we advertise it. As a starting point I assume we want to pitch it in the middle - some background, but also some specifics on the capabilities and where things fit. Thoughts for an outline; some of this is already in place, of course: Background to grid and GGF, including some history & definitions Where grid is being used now, importance in the commercial world, and the future Transition to SOA & Web services - why, and what it means Standards - why they're important, a review of relevant standards and SDOs, including latest news * Some specifics about OGSA: background, some info from the Roadmap, and an explanation of profiles Details of the OGSA capabilities and closely-related work - an intro diagram and a few slides on each - high-level intro, some detailed examples, status of work - we need to agree how technical we want to get, and try to keep all at the same level. e.g.: Infrastructure Security EMS Data Resource Mgmt Info CDDLM Self mgmt WS-Agreement Naming Any others? BUT: we will have to be conscious of time: I've already listed too much if capabilities average more than 3 minutes. So this is probably overly ambitious. Although we talked earlier about a 2-hour slot, I now know it's actually 90 minutes. [We'll have 30 minutes before the start for the presenters to get online and do logistics.] So the target for the presentation should be one hour, with the remainder for Q&A. Some time will be spent on preliminaries, so Q&A will probably be down to 20 mins. We probably won't have time to do audience polls, other than maybe one at the end while Q&A is in progress. Here are a few other things we'll need to provide ahead of time: * Title of presentation (e.g. "Defining the Grid: An Overview of OGSA") * Short abstract of session * Names of speaker(s) * Duration: Target one hour for presentation, 30 minutes for Q&A * Short bios for the speaker(s) -- two or three sentences each - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com> ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andrew Grimshaw Sent: Wednesday, March 15, 2006 10:22 AM To: 'ogsa-wg' Subject: [ogsa-wg] Webcast thoughts All, Id like to start an email discussion in advance of the F2F on the webcast content. While we do have an initial set of slides I think we need to make sure that we design the talk for our expected audience rather than based on the material we already have in the deck. When Dave I went to MS our slide deck was not technical enough we had the wrong talk with us, and so had to improvise. So, one of the things Id like to know is: Who is our expected audience? Is it technical people, if so, are they web services aware?, are they applications developers? Or are they mostly managers and planners. Or do we have to try and make everyone happy. Any insight? A Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu _______________________________________________________________ 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 <http://www.globus.org/>

1 0

RE: [ogsa-wg] Webcast thoughts (abstract)
by Ian Foster 24 Mar '06

24 Mar '06

Dear All: I'm concerned that a talk that focuses on the details of various specifications will not capture the imagination of the audience, especially as many of those specifications don't exist yet and/or have not been broadly adopted. I wonder if we should be thinking about a presentation that emphasizes more what this will let people do? Ian. At 12:21 PM 3/24/2006 -0500, Treadwell, Jem wrote: >"urn:schemas-microsoft-com:office:office" xmlns:w = >"urn:schemas-microsoft-com:office:word" xmlns:st1 = >"urn:schemas-microsoft-com:office:smarttags"> >Hi, the OGSA webcast is now confirmed for Wednesday April 26th. We'll be >discussing it on Monday's call and at the f2f in Sunnyvale. We plan to >hold a dry run on the regular con-call on Wednesday April 19th. It will >be hosted by HP; registration details to be announced. > >I need to provide an abstract and some other information, including >speaker bios, by next Wednesday, 3/29, so we will need to finalize the >abstract on Monday's call. My first draft is attached - if you have >comments or suggested changes please mark them up on the document and >return them to me as soon as possible, so that we can review them on the >call. Please don't wait until the call, as that will inevitably prolong >the discussion. > >Thanks! > >- Jem > >---------- >From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of >Treadwell, Jem >Sent: Monday, March 20, 2006 1:31 PM >To: Andrew Grimshaw; ogsa-wg >Subject: RE: [ogsa-wg] Webcast thoughts >Hi Andrew, sorry for the delayed response... for anyone wondering what >this is about, we're proposing to do a public webcast about OGSA, in the >April timeframe, and will have more details once the logistics have firmed >up a little more. HP will host. > >I've been working on the slides as a background activity, so please assume >I have the pen at the moment. I agree that they need augmenting for this. > >I think we can set our own expectations for the audience - we can say who >it's for when we advertise it. As a starting point I assume we want to >pitch it in the middle - some background, but also some specifics on the >capabilities and where things fit. Thoughts for an outline; some of this >is already in place, of course: >Background to grid and GGF, including some history & definitions Where >grid is being used now, importance in the commercial world, and the future >Transition to SOA & Web services - why, and what it means Standards - why >they're important, a review of relevant standards and SDOs, including >latest news > * Some specifics about OGSA: background, some info from the Roadmap, > and an explanation of profiles Details of the OGSA capabilities and > closely-related work - an intro diagram and a few slides on each - > high-level intro, some detailed examples, status of work - we need to > agree how technical we want to get, and try to keep all at the same > level. e.g.: > Infrastructure Security EMS Data Resource Mgmt Info CDDLM Self mgmt > WS-Agreement Naming Any others? > >BUT: we will have to be conscious of time: I've already listed too much if >capabilities average more than 3 minutes. So this is probably overly >ambitious. > >Although we talked earlier about a 2-hour slot, I now know it's actually >90 minutes. [We'll have 30 minutes before the start for the presenters to >get online and do logistics.] So the target for the presentation should >be one hour, with the remainder for Q&A. Some time will be spent on >preliminaries, so Q&A will probably be down to 20 mins. We probably won't >have time to do audience polls, other than maybe one at the end while Q&A >is in progress. > >Here are a few other things we'll need to provide ahead of time: > * Title of presentation (e.g. "Defining the Grid: An Overview of OGSA") > * Short abstract of session > * Names of speaker(s) > * Duration: Target one hour for presentation, 30 minutes for Q&A > * Short bios for the speaker(s) -- two or three sentences each > >- Jem > > >---------- >Jem Treadwell >Hewlett-Packard Company >6000 Irwin Road >Mount Laurel, NJ 08054 > >Phone: 856-638-6021 >Fax: 856-638-6190 >E-mail: <mailto:Jem.Treadwell@hp.com>Jem.Treadwell(a)hp.com > > > >---------- >From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of >Andrew Grimshaw >Sent: Wednesday, March 15, 2006 10:22 AM >To: 'ogsa-wg' >Subject: [ogsa-wg] Webcast thoughts > >All, > >Id like to start an email discussion in advance of the F2F on the webcast >content. While we do have an initial set of slides I think we need to make >sure that we design the talk for our expected audience rather than based >on the material we already have in the deck. When Dave I went to MS our >slide deck was not technical enough we had the wrong talk with us, and so >had to improvise. So, one of the things Id like to know is: Who is our >expected audience? Is it technical people, if so, are they web services >aware?, are they applications developers? Or are they mostly managers and >planners. Or do we have to try and make everyone happy. > > > >Any insight? > > > >A > > > >Andrew Grimshaw > >Professor of Computer Science > >University of Virginia > >434-982-2204 > >grimshaw(a)cs.virginia.edu > > > _______________________________________________________________ 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

RE: [ogsa-wg] Webcast thoughts (abstract)
by Treadwell, Jem 24 Mar '06

24 Mar '06

Hi, the OGSA webcast is now confirmed for Wednesday April 26th. We'll be discussing it on Monday's call and at the f2f in Sunnyvale. We plan to hold a dry run on the regular con-call on Wednesday April 19th. It will be hosted by HP; registration details to be announced. I need to provide an abstract and some other information, including speaker bios, by next Wednesday, 3/29, so we will need to finalize the abstract on Monday's call. My first draft is attached - if you have comments or suggested changes please mark them up on the document and return them to me as soon as possible, so that we can review them on the call. Please don't wait until the call, as that will inevitably prolong the discussion. Thanks! - Jem ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Treadwell, Jem Sent: Monday, March 20, 2006 1:31 PM To: Andrew Grimshaw; ogsa-wg Subject: RE: [ogsa-wg] Webcast thoughts Hi Andrew, sorry for the delayed response... for anyone wondering what this is about, we're proposing to do a public webcast about OGSA, in the April timeframe, and will have more details once the logistics have firmed up a little more. HP will host. I've been working on the slides as a background activity, so please assume I have the pen at the moment. I agree that they need augmenting for this. I think we can set our own expectations for the audience - we can say who it's for when we advertise it. As a starting point I assume we want to pitch it in the middle - some background, but also some specifics on the capabilities and where things fit. Thoughts for an outline; some of this is already in place, of course: * Background to grid and GGF, including some history & definitions * Where grid is being used now, importance in the commercial world, and the future * Transition to SOA & Web services - why, and what it means * Standards - why they're important, a review of relevant standards and SDOs, including latest news * Some specifics about OGSA: background, some info from the Roadmap, and an explanation of profiles * Details of the OGSA capabilities and closely-related work - an intro diagram and a few slides on each - high-level intro, some detailed examples, status of work - we need to agree how technical we want to get, and try to keep all at the same level. e.g.: * Infrastructure * Security * EMS * Data * Resource Mgmt * Info * CDDLM * Self mgmt * WS-Agreement * Naming * Any others? BUT: we will have to be conscious of time: I've already listed too much if capabilities average more than 3 minutes. So this is probably overly ambitious. Although we talked earlier about a 2-hour slot, I now know it's actually 90 minutes. [We'll have 30 minutes before the start for the presenters to get online and do logistics.] So the target for the presentation should be one hour, with the remainder for Q&A. Some time will be spent on preliminaries, so Q&A will probably be down to 20 mins. We probably won't have time to do audience polls, other than maybe one at the end while Q&A is in progress. Here are a few other things we'll need to provide ahead of time: * Title of presentation (e.g. "Defining the Grid: An Overview of OGSA") * Short abstract of session * Names of speaker(s) * Duration: Target one hour for presentation, 30 minutes for Q&A * Short bios for the speaker(s) -- two or three sentences each - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com> ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andrew Grimshaw Sent: Wednesday, March 15, 2006 10:22 AM To: 'ogsa-wg' Subject: [ogsa-wg] Webcast thoughts All, I'd like to start an email discussion in advance of the F2F on the webcast content. While we do have an initial set of slides - I think we need to make sure that we design the talk for our expected audience - rather than based on the material we already have in the deck. When Dave I went to MS our slide deck was not technical enough - we had the wrong talk with us, and so had to improvise. So, one of the things I'd like to know is: Who is our expected audience? Is it technical people, if so, are they web services aware?, are they applications developers? Or are they mostly managers and planners. Or do we have to try and make everyone happy. Any insight? A Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

1 0

Hotel in Sunnyvale
by Mark Morgan 23 Mar '06

23 Mar '06

As some of you know from the telecon this afternoon, the Corporate Inn is booked, but it's sister hotel (which is Supposedly located withing walking distance of the Corporate Inn) is available at the Fujitzu rate of $99/night. The information for that hotel is: St. Francis Arms http://stfrancisarms.com/html/location.html -Mark

3 2

RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Ian Foster 23 Mar '06

23 Mar '06

Marvin: I'm sure you are wrong in impying that systems such as LSF do not write information about jobs to stable storage. LSF and other similar systems MUST be highly reliable so that they can guarantee that jobs will not be lost. I am sure that this means that they write some record of each job submitted to stable storage. Chris or others will I am sure correct me if I am wrong in this assertion. That said, I certainly agree that we need input from the scheduler developers. We should be careful not to use the word "transactional semantics" as that is not what we are talking about. Ian. At 05:14 PM 3/21/2006 -0800, Marvin Theimer wrote: >Hi; > > > >I know that systems like LSF get used in high throughput settings where >the service time for a job request is an issue. An example is running >very large numbers of relatively short jobs through a compute >cluster. Implementing at-most-once semantics implies doing disk writes to >get the necessary persistency. Im just speculating, but doing those disk >writes efficiently enough (e.g. via group commits) to support the >throughputs that Ive been told of by, for example, customers in the >financial industry is not a trivial design and implementation task. If my >assumption is correct, then this common use case in the HPC world may be >one that many, if not most job schedulers would have a hard time >supporting if they have to provide at-most-once transactional semantics >for all job submissions. > > > >So do we exclude that use case and tell the scheduler vendors servicing >that market that they need to come up with a separate interaction protocol >for that use case? I would prefer to define a base use case without >transactional semantics and immediately also define an extension that >provides those semantics. Any scheduler wanting to play in the wider grid >world would implement the extension because clients will be looking >for/insisting on it. Any scheduler wanting to provide >ultra-high-throughput non-transactional semantics could do so via the base >case. Providing a front-end that implements transactional semantics for a >high-throughput scheduler is arguably better and easier than forcing the >high throughput-scheduler to implement either a complicated >high-performance job metadata repository or an additional separate >protocol for the ultra-high-throughput case. > > > >Now, of course, it may be the case that its really not that hard to >provide transactional semantics for such ultra-high-throughput use cases >for all the schedulers we care about; in which case Id be thrilled to >agree to include them in the base use case and move on. This is where Id >really like to obtain input/guidance from representatives of those >scheduler vendors/suppliers. If anyone from Platform Computing, Altair, >SUN, and the other scheduler vendor/providers is monitoring this email >thread then please speak up! > > > >Marvin. > > > >---------- >From: Ian Foster [mailto:foster@mcs.anl.gov] >Sent: Tuesday, March 21, 2006 10:53 AM >To: Marty Humphrey; Marvin Theimer; 'Carl Kesselman' >Cc: ogsa-wg(a)ggf.org; Marvin Theimer >Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > > > >Marty: > >I wasn't trying to be philosophical, just commenting that >at-once-submission semantics is important. If a client can't be sure that >a job is submitted or not, clients get very complicated. > >Ian. > > >At 01:43 PM 3/21/2006 -0500, Marty Humphrey wrote: > > >But this is not so simple. The knee-jerk reaction is to separate these two >concerns into implementation vs. interface, and develop each one >independently. But taken to the extreme, a system that appearsto be rich >in its capabilities might not be so in reality for some time (if EVER!). > > > >Lets assume that we truly separate these concerns and build sophisticated >interfaces. But then what about the potential consumer of such services? >Building an overly complex interface to such a service (without any >practical implementations behind it) might promote further complicated >clients (which promotes further complexity upstream&) Build the interface >and they will come with implementationsis a variation on a theme that >doesnt always come true. Arguably, complexity is what were trying to get >away from. > > > >And no, Im not advocating only an interface that matches existing >capabilities. Im just saying that its NOT obvious that the most effective >approach is to entirely decouple these two concerns. > > > >-- Marty > > > >---------- >From: Ian Foster [mailto:foster@mcs.anl.gov] >Sent: Tuesday, March 21, 2006 1:34 PM >To: Marvin Theimer; Carl Kesselman >Cc: humphrey(a)cs.virginia.edu; ogsa-wg(a)ggf.org; Marvin Theimer >Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > > > >Marvin: > >I think you are mixing two things together: the capabilities of the >scheduler and the capabilities of the remote submission interface. The >proposal that we submit at-most-once submission capabilities is a proposal >for capabilities in the remote submission interface, not the scheduler. I >wouldn't expect existing schedulers to provide this capability, just as >they don't (for the most part) support Web Services interfaces. But once >we define a Web Services-based remote submission interface, at-most-once >submission capabilities become important. > >Ian. > > >At 10:28 AM 3/21/2006 -0800, Marvin Theimer wrote: > > >Hi; > > > >Whereas I agree with you that at-most-once semantics are very desirable, I >would like to point out that not all existing job schedulers implement >them. I know that both LSF and CCS (the Microsoft HPC job scheduler) >dont. Ive been trying to find out whether PBS and SGE do or dont. > > > >So, this brings up the following slightly more general question: should >the simplest base case be the simplest case that does something useful, or >should it be more complicated than that? I can see good arguments on both >sides: > >· Whittling things down to the simplest possible base case >maximizes the likelihood that parties can participate. Every feature >added represents one more feature that some existing system may not be >able to support or that a new system has to provide even when its not >needed in the context of that system. Suppose, for example, that PBS and >SGE dont provide transactional semantics of the type you described. Then >4 of the 6 most common job scheduling systems would not have this feature >and would need to somehow add it to their implementations. In this >particular case it might be too difficult to add in practice, but in >general there might be problems. > >· On the other hand, since there are many clients and arguably far >fewer server implementations, features that substantially simplify client >behavior/programming and that are not too onerous to implement in existing >and future systems should be part of the base case. The problem, of >course, is that this is a slippery slope at the end of which lies the >number 42 (ignore that last phrase if youre not a fan of The Hitchhikers >Guide to the Galaxy). > > > >Personally, the slippery slope argument makes me lean towards defining the >simplest possible base use case, since otherwise well spend a (potentially >very) long time arguing about which features are important enough to >justify being in the base case. One possible way forward on this issue is >to have people come up with lists of features that they feel belong in the >base use case and then we agree to include only those that have a large >majority of the community arguing for their inclusion in the base case. > > > >Unfortunately defining what large majorityshould be is also not easy or >obvious. Indeed, one can argue that we cant even afford to let all votes >be equal. Consider the following hypothetical (and contrived) case: 100 >members of a particular academic research community show up and vote that >the base case must include support for a particular complicated scheduling >policy and the less-than-ten suppliers of existing job schedulers with >significant numbers of users all vote against it. Should it be included >in the base case? What happens if the major scheduler vendors/suppliers >decide that they cant justify implementing it and therefore cant be GGF >spec-compliant and therefore go off and define their own job scheduling >standard? The hidden issue is, of course, whether those voting are >representative of the overall HPC user population. I cant personally >answer that question, but it does again lead me to want to minimize the >number of times I have to ask that question i.e. the number of features >that I have to consider for inclusion in the base case. > > > >So this brings me to the question of next steps. Recall that the approach >Im advocating and that others have bought in to as far as I can tell is >that we define a base case and the mechanisms and approach to how >extensions of the base case are done. I assert that the absolutely most >important part of defining how extension should work is ensuring that >multiple extensions dont end up producing a hairball thats impossible to >understand, implement, or use. In practice this means coming up with a >restricted form of extension since history is pretty clear on the pitfalls >of trying to support arbitrarily general extension schemes. > > > >This is one of the places where identification of common use cases comes >in. If we define the use cases that we think might actually occur then we >can ask whether a given approach to extension has a plausible way of >achieving all the identified use cases. Of course, future desired use >cases might not be achievable by the extension schemes we come up with >now, but that possibility is inevitable given anything less than a fully >general extension scheme. Indeed, even among the common use cases we >identify now, we might discover that there are trade-offs where a simpler >(and hence probably more understandable and easier to implement and use) >extension scheme can cover 80% of the use cases while a much more >complicated scheme is required to cover 100% of the use cases. > > > >Given all this, here are the concrete next steps Id like to propose: > >· Everyone who is participating in this design effort should >define what they feel should be the HPC base use case. This represents >the simplest use case and associated features like transactional submit >semantics that you feel everyone in the HPC grid world must implement. We >will take these use case candidates and debate which one to actually settle on. > >· Everyone should define the set of HPC use cases that they >believe might actually occur in practice. I will refer to these as the >common use cases, in contrast to the base use case. The goal here is not >to define the most general HPC use case, but rather the more restricted >use cases that might occur in real life. For example, not all systems >will support job migration, so whereas a fully general HPC use case would >include the notion of job migration, I argue that one or more common use >cases will not include job migration. > >Everyone should also prioritize and rank their common use cases so that we >can discuss 80/20-style trade-offs concerning which use cases to support >with any given approach to extension. Thus prioritization should include >the notion of how common you think a use case will actually be, and hence >how important it will be to actually support that use case. > >· Everyone should start thinking about what kinds of extension >approaches they believe we should define, given the base use case and >common use cases that they have identified. > > > >As multiple people have pointed out, an exploration of common HPC use >cases has already been done one or several times before, including in the >EMS working group. Im still catching up on reading GGF documents, so I >dont know how much those prior efforts explored the issue from the >point-of-view of base case plus extensions. If these prior explorations >did address the topic of base-plus-extensions and you agree with the >specifics that were arrived at then this exercise will be a quick-and-easy >one for you: you can simply publish the appropriate links to prior >material in an email to this mailing list. I will personally be sending >in my list independent of prior efforts in order to provide a >newcomersperspective on the subject. It will interesting to see how much >overlap there is. > > > >One very important point that Id like to raise is the following: Time is >short and bestis the enemy of good enough. Microsoft is planning to >provide a Web services-based interoperability interface to its job >scheduler sometime in the next year or two. I know that many of the other >job scheduler vendors/suppliers are also interested in having an >interoperability story in place sooner rather than later. To meet this >schedule on the Microsoft side will require locking down a first fairly >complete draft of whatever design will be shipped by essentially the end >of August. That's so that we can do all the necessary debugging, >interoperability testing, security threat modeling, etc. that goes with >shipping an actual finished product. What that means for the HPC profile >work is that, come the end of August, Microsoft and possibly other >scheduler vendors/suppliers will need to lock down and start coding some >version of Web Services-based job scheduling and data transfer >protocols. If there is a fairly well-defined, feasible set of >specs/profile coming out of the GGF HPC working group (for recommendation >NOT yet for actual standards approval) that has some reasonable level of >consensus by then, then that's what Microsoft will very likely go >with. Otherwise Microsoft will need to defer the idea of shipping >anything that might be GGF compliant to version 3 of our product, which >will probably ship about 4 years from now. > > > >The chances of coming up with the bestHPC profile by the end of August are >slim. The chances of coming up with a fairly simple design that is good >enoughto cover the most important common cases by means of a relatively >simple, restricted form of extension seems much more feasible. Covering a >richer set of use cases would need to be deferred to a future version of >the profile, much in the manner that BES has been defined to cover an >important sub-category of use cases now, with a fuller EMS design being >done in parallel as future work. So I would argue that perhaps the most >important thing this design effort and the planned HPC profile working >group that will be set up in Tokyo can do is to identify what a good >enoughversion 1 HPC profile should be. > > > >Marvin. > > > > > >---------- >From: Carl Kesselman [mailto:carl@isi.edu] >Sent: Thursday, March 16, 2006 12:49 AM >To: Marvin Theimer >Cc: humphrey(a)cs.virginia.edu; ogsa-wg(a)ggf.org >Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > > > >Hi, > >In the interest of furthering agreement, I was not arguing that the >application had to be restartable. Rather, what has been shown to be >important is that the protocol be restartable in the following sense: if >you submit a job and the far and server fails, is the job running or not, >if you resubmit, do you get another job instance. The GT sumbission >protocol and Condor have a transactional semantics so that you can have at >most once submit semantics reegardless of client and server failures. The >fact that your application may be non-itempote is exactly why having a >well defined semantics in this case is important. > >So what is the next step? > >Carl > >Dr. Carl Kesselman email: carl(a)isi.edu >USC/Information Sciences Institute WWW: ><http://www.isi.edu/~carl>http://www.isi.edu/~carl >4676 Admiralty Way, Suite 1001 Phone: (310) 448-9338 >Marina del Rey, CA 90292-6695 Fax: (310) 823-6714 > > > >-----Original Message----- >From: Marvin Theimer <theimer(a)microsoft.com> >To: Carl Kesselman <carl(a)isi.edu> >CC: Marvin Theimer <theimer(a)microsoft.com>; Marty Humphrey ><humphrey(a)cs.virginia.edu>; ogsa-wg(a)ggf.org <ogsa-wg(a)ggf.org> >Sent: Wed Mar 15 14:26:36 2006 >Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > >Hi; > > > >I suspect that were mostly in agreement on things. In particular, I think >your list of four core aspects is a great starting point for a discussion >on the topic. > > > >I just replied to an earlier email from Ravi with a description of what Im >hoping to get out of examining various HPC use cases: > >· Identification of the simplest base case that everyone will have >to implement. > >· Identification of common cases we want to optimize. > >· Identification of how evolution and selective extension will work. > > > >I totally agree with you that the base use case I described isnt really a >griduse case. But it is an HPC use case in fact it is arguably the most >common use case in current existence. J So I think its important that we >understand how to seamlessly integrate and support that common and very >simple use case. > > > >I also totally agree with you that we cant let a solution to the simplest >HPC use case paint us into a corner that prevents supporting the richer >use cases that grid computing is all about. Thats why Id like to spend >significant effort exploring and understanding the issues of how to >support evolution and selective extension. In an ideal world a legacy >compute cluster job scheduler could have a simple grid shimthat let it >participate at a basic level, in a natural manner, in a grid environment, >while smarter clients and HPC services could interoperate with each other >in various selectively richer manners by means of extensions to the basic >HPC grid design. > > > >One place where I disagree with you is your assertion that everything >needs to be designed to be restartable. While thats a good goal to pursue >Im not convinced that you can achieve it in all cases. In particular, >there are at least two cases that I claim we want to support that arent >restartable: > >· We want to be able to run applications that arent restartable; >for example, because they perform non-idempotent operations on the >external physical environment. If such an application fails during >execution then the only one who can figure out what the proper next steps >are is the end user. > >· We want to be able to include (often-times legacy) systems that >arent fault tolerant, such as simple small compute clusters where the >owners didnt think that fault tolerance was worth paying for. > >Of course any acceptable design will have to enable systems that are fault >tolerant to export/expose that capability. To my mind its more a matter >of ensuring that non-fault-tolerant systems arent excluded from >participation in a grid. > > > >Other things we agree on: > >· We should certainly examine what remote job submission systems >do. We should certainly look at existing systems like Globus, Unicore, >and Legion. In general, we should be looking at everything that has any >actual experience that we can learn from and everything that is actually >deployed and hence represents a system that we potentially need to >interoperate with. (Whether a final design is actually able to >interoperate at any but the most basic level with various exotic existing >systems is a separate issue.) > >· We should absolutely focus on codifying what we know how to do >and avoid doing research as part of a standards process. I believe that >thinking carefully about how to support evolution and extension is our >best hope for allowing people to defer trying to bake their pet research >topic into standards since it provides a story for why todays standards >dont preclude tomorrows improvements. > > > >So I would propose that next steps are: > >· Continue to explore and classify various HPC use cases of various >differing levels of complexity. > >· Describe the requirements and limitations of existing job >scheduling and remote job submission systems. > >· Continue identifying and discussing key featuresof use cases and >potential design solutions, such as the four that you identified in your >last email. > > > >Marvin. > > > >________________________________ > >From: Carl Kesselman [<mailto:carl@isi.edu>mailto:carl@isi.edu] >Sent: Tuesday, March 14, 2006 7:50 AM >To: Marty Humphrey; ogsa-wg(a)ggf.org >Cc: Marvin Theimer >Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > > > >Hi, > > > >Just to be clear, Im not trying to suggest that the scope be expanded. I >agree with the approach of focusing on a baby step is a good one, and many >of the assumptions stated in Marvins list I am in total agreement with. >However, in taking baby steps I think that it is important that we end up >walking, and that in defining the use case, one can easily create >solutions that will not get you to the next step. This is my point about >looking at what we know how to do and have been doing in production >settings for many years now. In my mind, one of the scope grandness >problems has been that there has been far too little focus on codifying >what we know how to do in favor of using a standards process as an excuse >to design new things. So at the risk of sounding partisan, the simplified >use case that Marvin is proposing is exactly the use case that GRAM has >been doing for over ten years now (I think the same can be said about >UNICORE and Legion). > > > >So let me try to be constructive. One of the things that falls out of >Marvins list could be a set of basic concepts/operations that need to be >defined. These include: > >1) A way of describing localjob configuration, i.e. where to find the >executable, data files, etc. This should be very conservative with its >assumptions on shared file systems and accessibility. In general, what >needs to be stated here are what are the underlying aspects of the >underlying resource that are exposed to the outward facing interface. > >2) A way of naming a submission point (should probably have a way of >modeling queues). > >3) A core set of job management operations, submit, status, kill. These >need to be defined in such a way at to be tolerate to a variety of failure >scenarios, in that the state needs to be well defined in the case of failure. > >4) A state model that one can use to describe what is going on with the >jobs and a way to access that state. Can be simple (queued, running, >done), may need to be extensible. One can view the accounting information >as being exposed > > > >So, one thing to do would be to agree that these are (or are not) the >right four things that need to be defined and if so, start to flesh out >these in a way that supports the core use case but doesnt introduce >assumptions that would preclude more complex use cases in the future. > > > > > >Carl > > > >________________________________ > >From: owner-ogsa-wg(a)ggf.org >[<mailto:owner-ogsa-wg@ggf.org>mailto:owner-ogsa-wg@ggf.org] On Behalf Of >Marty Humphrey >Sent: Tuesday, March 14, 2006 6:32 AM >To: ogsa-wg(a)ggf.org >Cc: 'Marvin Theimer' >Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > > > >Carl, > > > >Your comments are very important. We would love to have your active >participation in this effort. Your experience is, of course, matched by few! > > > >I re-emphasize that this represents (my words, not anyone elses) baby >stepsthat are necessary and important for the Grid community. In my >opinion, the biggest challenge will be to fight the urge to expand the >scope beyond a small size. You cannot ignore the possibility that the GGF >has NOT made as much progress as it should have to date. Furthermore, one >such plausible explanation is that the scope is too grand. > > > >-- Marty > > > > > >________________________________ > >From: owner-ogsa-wg(a)ggf.org >[<mailto:owner-ogsa-wg@ggf.org>mailto:owner-ogsa-wg@ggf.org] On Behalf Of >Carl Kesselman >Sent: Tuesday, March 14, 2006 8:47 AM >To: Marvin Theimer; Ian Foster; ogsa-wg(a)ggf.org >Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > > > >Hi, > > > >While I have no wish to engage in the what is a Gridargument, there are >some elements of your base use case that I would be concerned >about. Specifically, the assumption that the submission in into a local >clusteron which there is an existing account may lead one to a solution >that may not generalize to the solution to the case of submission across >autonomous policy domains. I would also argue that ignoring issues of >fault tolerance from the beginning is also problematic. One must at least >design operations that are restartable (for example at most once >submission semantics). > > > >I would finally suggest that while examining existing job schedule systems >is a good thing to do, we should also examine existing remote submission >systems (dare I say Grid systems). The basic HPC use case is one in which >there is a significant amount implementation and usage experience. > > > >Thanks, > > >Carl > > > > > >________________________________ > >From: owner-ogsa-wg(a)ggf.org >[<mailto:owner-ogsa-wg@ggf.org>mailto:owner-ogsa-wg@ggf.org] On Behalf Of >Marvin Theimer >Sent: Monday, March 13, 2006 2:42 PM >To: Ian Foster; ogsa-wg(a)ggf.org >Cc: Marvin Theimer >Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > > > >Hi; > > > >Ian, you are correct that I view job submission to a cluster as being one >of the simplest, and hence most basic, HPC use cases to start with. Or, >to be slightly more general, I view job submission to a black boxthat can >run jobs be it a cluster or an SMP or an SGI NUMA machine or what-have-you >as being the simplest and hence most basic HPC use case to start >with. The key distinction for me is that the internals of the boxare for >the most part not visible to the client, at least as far as submitting and >running compute jobs is concerned. There may well be a separate interface >for dealing with things like system management, but I want to explicitly >separate those things out in order to allow for use of boxesthat might be >managed by proprietary means or by means obeying standards that a >particular job submission client is unfamiliar with. > > > >I think the use case that Ravi Subramaniam posted to this mailing list >back on 2/17 is a good one to start a discussion around. However, Id like >to present it from a different point-of-view than he did. The manner in >which the use case is currently presented emphasizes all the capabilities >and services needed to handle the fully general case of submitting a batch >job to a computing utility/service. Thats a great way of producing a >taxonomy against which any given system or design can be compared to see >what it has to offer. I would argue that the next step is to ask whats >the simplest subset that represents a useful system/design and how should >one categorize the various capabilities and services he has identified so >as to arrive at meaningful components that can be selectively used to >obtain progressively more capable systems. > > > >Another useful exercise to do is to examine existing job scheduling >systems in order to understand what they provide. Since in the real world >we will have to deal with the legacy of existing systems it will be >important to understand how they relate to the use cases we explore. In >the same vein, it will be important to take into account and understand >other existing infrastructures that people use that are related to HPC use >cases. Im thinking of things like security infrastructures, directory >services, and so forth. From the point-of-view of managing complexity and >reducing total-cost-of-ownership, it will be important to understand the >extent to which existing infrastructure and services can be reused rather >than reinvented. > > > >To kick off a discussion around the topic of a minimalist HPC use case, I >present a straw man description of such below and then present a first >attempt at categorizing various areas of extension. The categorization of >extension areas is not meant to be complete or even all that carefully >thought-out as far as componentization boundaries are concerned; it is >merely meant to be a first contribution to get the discussion going. > > > >A basic HPC use case: Compute cluster embedded within an organization. > >· This is your basic batch job scheduling scenario. Only a very basic >state transition diagram is visible to the client, with the following >states for a job: queued, running, finished. Additional states -- and >associated state transition request operations and functionality -- are >not supported. Examples of additional states and associated functionality >include suspension of jobs and migration of jobs. > >· Only "standard" resources can be described, for example: number of >cpus/nodes needed, memory requirements, disk requirements, etc. (think >resources that are describable by JSDL). > >· Once a job has been submitted it can be cancelled, but its resource >requests can't be modified. > >· A distributed file system is accessible from client desktop machines >and client file servers, as well as compute nodes of the compute >cluster. This implies that no data staging is required, that programs can >be (for the most part) executed from existing file system locations, and >that no program "provisioning" is required (since you can execute them >from wherever they are already installed). Thus in this use case all data >transfer and program installation operations are the responsibility of the >user. > >· Users already have accounts within the existing security >infrastructure (e.g. Kerberos). They would like to use these and not have >to create/manage additional authentication/authorization credentials (at >least at the level that is visible to them). > >· The job scheduling service resides at a well-known network name and >it is aware of the compute cluster and its resources by "private" means >(e.g. it runs on the head node of the cluster and employs private means to >monitor and control the resources of the cluster). This implies that >there is no need for any sort of directory services for finding the >compute cluster or the resources it represents other than basic DNS. > >· Compute cluster system management is opaque to users and is the >concern of the compute cluster's owners. This implies that system >management is not part of the compute cluster's public job scheduling >interface. This also implies that there is no need for a logging >interface to the service. I assume that application-level logging can be >done by means of libraries that write to client files; i.e. that there is >no need for any sort of special system support for logging. > >· A simple polling-based interface is the simplest form of interface >to something like a job scheduling service. However, a simple call-back >notification interface is a very useful addition that potentially provides >substantial performance benefits since it can enable the avoidance of lots >of unnecessary network traffic. Only job state changes result in >notification messages. > >· There are no notions of fault tolerance. Jobs that fail must be >resubmitted by the client. Neither the cluster head node nor its compute >nodes are fault tolerant. I do expect the client software to return an >indication of failure-due-system-fault when appropriate. (Note that this >may also occur when things like network partitions occur.) > >· One does need some notion of how to deal with orphaned resources and >jobs. The notion of job lifetime and post-expiration garbage collection >is a natural approach here. > >· The scheduling service provides a fixed set of scheduling policies, >with only a few basic choices (or maybe even just one), such as FIFO or >round-robin. There is no notion, in general, of SLAs (which are a form of >scheduling policy). > >· Enough information must be returned to the client when a job >finishes to enable basic accounting functionality. This means things like >total wall-clock time the job ran and a summary of resources used. There >is not a need for the interface to support any sort of grouping of >accounting information. That is, jobs do not need to be associated with >projects, groups, or other accounting entities and the job scheduling >service is not responsible for tracking accounting information across such >entities. As long as basic resource utilization information is returnable >for each job, accounting can be done externally to the job scheduling >service. I do assume that jobs can be uniquely identified by some means >and can be uniquely associated with some principal entity existing in the >overall system, such as a user name. > >· Just as there is no notion of requiring the job scheduling service >to track any but the most basic job-level accounting information, there is >no notion of the service enforcing quotas on jobs. > >· Although it is generally useful to separate the notions of resource >reservation from resource usage (e.g. to enable interactive and debugging >use of resources), it is not a necessity for the most basic of job >scheduling services. > >· There is no notion of tying multiple jobs together, either to >support things like dependency graphs or to support things like >workflows. Such capabilities must be implemented by clients of the job >scheduling service. > > > >Interesting extension areas: > >· Additional scheduling policies > >o Weighted fair-share, & > >o Multiple queues > >o SLAs > >o ... > >· Extended resource descriptions > >o Additional resource types, such as GPUs > >o Additional types of compute resources, such as desktop computers > >o Condor-style class ads > >· Extended job descriptions (as returned to requesting clients and >sys admins) > >· Additional classes of security credentials > >· Reservations separated from execution > >o Enabling interactive and debugging jobs > >o Support for multiple competing schedulers (incl. desktop cycle >stealing and market-based approaches to scheduling compute resources) > >· Ability to modify jobs during their existence > >· Fault tolerance > >o Automatic rescheduling of jobs that failed due to system faults > >o Highly available resources: This is partly a policy statement by a >scheduling service about its characteristics and partly the ability to >rebind clients to migrated service endpoints > >· Extended state transition diagrams and associated functionalities > >o Job suspension > >o Job migration > >o & > >· Accounting & quotas > >· Operating on arrays of jobs > >· Meta-schedulers, multiple schedulers, and ecologies and hierarchies >of multiple schedulers > >o Meta-schedulers > >· Hierarchical job scheduling with a meta-scheduler as the only entry >point; forwarding jobs to the meta-scheduler from other subsidiary schedulers > >o Condor-style matchmaking > >· Directory services > >o Using existing directory services > >o Abstract directory service interface(s) > >· Data transfer topics > >o Application data staging > >· Naming > >· Efficiency > >· Convenience > >· Cleanup > >o Program staging/provisioning > >· Description > >· Installation > >· Cleanup > > > > > >Marvin. > > > >________________________________ > >From: Ian Foster [<mailto:foster@mcs.anl.gov>mailto:foster@mcs.anl.gov] >Sent: Monday, February 20, 2006 9:20 AM >To: Marvin Theimer; ogsa-wg(a)ggf.org >Cc: Marvin Theimer; Savas Parastatidis; Tony Hey; Marty Humphrey; >gcf(a)grids.ucs.indiana.edu >Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > > > >Dear All: > >The most important thing to understand at this point (IMHO) is the scope >of this "HPC use case," as this will determine just how minimal we can be. > >I get the impression that the principal goal may be "job submission to a >cluster." Is that correct? How do we start to circumscribe the scope more >explicitly? > >Ian. > > > >At 05:45 AM 2/16/2006 -0800, Marvin Theimer wrote: > >Enclosed is a paper that advocates an additional set of activities that >the authors believe that the OGSA working groups should engage in. > > > >Broadly speaking, the OGSA and related working groups are already doing a >bunch of important things: > >· There is broad exploration of the big picture, including >enumeration of use cases, taxonomy of areas, identification of research >issues, etc. > >· There is work going on in each of the horizontal areas that have >been identified, such as EMS, data services, etc. > >· There is working going around individual specifications, such as >BES, JSDL, etc. > > > >Given that individual specifications are beginning to come to fruition, >the authors believe it is time to also start defining vertical >profilesthat precisely describe how groups of individual specifications >should be employed to implement specific use cases in an interoperable >manner. The authors also believe that the process of defining these >profiles offers an opportunity to close the design loopby relating the >various on-going protocol and standards efforts back to the use cases in a >very concrete manner. This provides an end-to-end setting in which to >identify holes and issues that might require additional protocols and/or >(incremental) changes to existing protocols. The paper introduces both >the general notion of doing focused vertical design effortsand then >focuses on a specific vertical design effort, namely a minimal HPC design. > > > >The paper derives a specific HPC design in a first principlesmanner since >the authors believe that this increases the chances of identifying >issues. As a consequence, existing specifications and the activities of >existing working groups are not mentioned and this paper is not an attempt >to actually define a specifications profile. Also, the absence of >references to existing work is not meant to imply that such work is in any >way irrelevant or inappropriate. The paper should be viewed as a first >abstract attempt to propose a new kind of activity within OGSA. The >expectation is that future open discussions and publications will explore >the concrete details of such a proposal. > > > >This paper was recently sent to a few key individuals in order to get >feedback from them before submitting it to the wider GGF >community. Unfortunately that process took longer than intended and some >members of the community may have already seen a copy of the paper without >knowing the context within it was written. This email should hopefully >dispel any misconceptions that may have occurred. > > > >For those people who will be around on for the F2F meetings on Friday, >Marvin Theimer will be giving a talk on the contents of this paper at a >time and place to be announced. > > > >Marvin Theimer, Savas Parastatidis, Tony Hey, Marty Humphrey, Geoffrey Fox > > > >_______________________________________________________________ >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 > <<http://www.globus.org/>http://www.globus.org/> > >_______________________________________________________________ >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 > >_______________________________________________________________ >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 _______________________________________________________________ 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

4 4

RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Ian Foster 23 Mar '06

23 Mar '06

Marvin: I think you are mixing two things together: the capabilities of the scheduler and the capabilities of the remote submission interface. The proposal that we submit at-most-once submission capabilities is a proposal for capabilities in the remote submission interface, not the scheduler. I wouldn't expect existing schedulers to provide this capability, just as they don't (for the most part) support Web Services interfaces. But once we define a Web Services-based remote submission interface, at-most-once submission capabilities become important. Ian. At 10:28 AM 3/21/2006 -0800, Marvin Theimer wrote: >Hi; > > > >Whereas I agree with you that at-most-once semantics are very desirable, I >would like to point out that not all existing job schedulers implement >them. I know that both LSF and CCS (the Microsoft HPC job scheduler) >dont. Ive been trying to find out whether PBS and SGE do or dont. > > > >So, this brings up the following slightly more general question: should >the simplest base case be the simplest case that does something useful, or >should it be more complicated than that? I can see good arguments on both >sides: > >· Whittling things down to the simplest possible base case >maximizes the likelihood that parties can participate. Every feature >added represents one more feature that some existing system may not be >able to support or that a new system has to provide even when its not >needed in the context of that system. Suppose, for example, that PBS and >SGE dont provide transactional semantics of the type you described. Then >4 of the 6 most common job scheduling systems would not have this feature >and would need to somehow add it to their implementations. In this >particular case it might be too difficult to add in practice, but in >general there might be problems. > >· On the other hand, since there are many clients and arguably far >fewer server implementations, features that substantially simplify client >behavior/programming and that are not too onerous to implement in existing >and future systems should be part of the base case. The problem, of >course, is that this is a slippery slope at the end of which lies the >number 42 (ignore that last phrase if youre not a fan of The Hitchhikers >Guide to the Galaxy). > > > >Personally, the slippery slope argument makes me lean towards defining the >simplest possible base use case, since otherwise well spend a (potentially >very) long time arguing about which features are important enough to >justify being in the base case. One possible way forward on this issue is >to have people come up with lists of features that they feel belong in the >base use case and then we agree to include only those that have a large >majority of the community arguing for their inclusion in the base case. > > > >Unfortunately defining what large majorityshould be is also not easy or >obvious. Indeed, one can argue that we cant even afford to let all votes >be equal. Consider the following hypothetical (and contrived) case: 100 >members of a particular academic research community show up and vote that >the base case must include support for a particular complicated scheduling >policy and the less-than-ten suppliers of existing job schedulers with >significant numbers of users all vote against it. Should it be included >in the base case? What happens if the major scheduler vendors/suppliers >decide that they cant justify implementing it and therefore cant be GGF >spec-compliant and therefore go off and define their own job scheduling >standard? The hidden issue is, of course, whether those voting are >representative of the overall HPC user population. I cant personally >answer that question, but it does again lead me to want to minimize the >number of times I have to ask that question i.e. the number of features >that I have to consider for inclusion in the base case. > > > >So this brings me to the question of next steps. Recall that the approach >Im advocating and that others have bought in to as far as I can tell is >that we define a base case and the mechanisms and approach to how >extensions of the base case are done. I assert that the absolutely most >important part of defining how extension should work is ensuring that >multiple extensions dont end up producing a hairball thats impossible to >understand, implement, or use. In practice this means coming up with a >restricted form of extension since history is pretty clear on the pitfalls >of trying to support arbitrarily general extension schemes. > > > >This is one of the places where identification of common use cases comes >in. If we define the use cases that we think might actually occur then we >can ask whether a given approach to extension has a plausible way of >achieving all the identified use cases. Of course, future desired use >cases might not be achievable by the extension schemes we come up with >now, but that possibility is inevitable given anything less than a fully >general extension scheme. Indeed, even among the common use cases we >identify now, we might discover that there are trade-offs where a simpler >(and hence probably more understandable and easier to implement and use) >extension scheme can cover 80% of the use cases while a much more >complicated scheme is required to cover 100% of the use cases. > > > >Given all this, here are the concrete next steps Id like to propose: > >· Everyone who is participating in this design effort should >define what they feel should be the HPC base use case. This represents >the simplest use case and associated features like transactional submit >semantics that you feel everyone in the HPC grid world must implement. We >will take these use case candidates and debate which one to actually settle on. > >· Everyone should define the set of HPC use cases that they >believe might actually occur in practice. I will refer to these as the >common use cases, in contrast to the base use case. The goal here is not >to define the most general HPC use case, but rather the more restricted >use cases that might occur in real life. For example, not all systems >will support job migration, so whereas a fully general HPC use case would >include the notion of job migration, I argue that one or more common use >cases will not include job migration. > >Everyone should also prioritize and rank their common use cases so that we >can discuss 80/20-style trade-offs concerning which use cases to support >with any given approach to extension. Thus prioritization should include >the notion of how common you think a use case will actually be, and hence >how important it will be to actually support that use case. > >· Everyone should start thinking about what kinds of extension >approaches they believe we should define, given the base use case and >common use cases that they have identified. > > > >As multiple people have pointed out, an exploration of common HPC use >cases has already been done one or several times before, including in the >EMS working group. Im still catching up on reading GGF documents, so I >dont know how much those prior efforts explored the issue from the >point-of-view of base case plus extensions. If these prior explorations >did address the topic of base-plus-extensions and you agree with the >specifics that were arrived at then this exercise will be a quick-and-easy >one for you: you can simply publish the appropriate links to prior >material in an email to this mailing list. I will personally be sending >in my list independent of prior efforts in order to provide a >newcomersperspective on the subject. It will interesting to see how much >overlap there is. > > > >One very important point that Id like to raise is the following: Time is >short and bestis the enemy of good enough. Microsoft is planning to >provide a Web services-based interoperability interface to its job >scheduler sometime in the next year or two. I know that many of the other >job scheduler vendors/suppliers are also interested in having an >interoperability story in place sooner rather than later. To meet this >schedule on the Microsoft side will require locking down a first fairly >complete draft of whatever design will be shipped by essentially the end >of August. That's so that we can do all the necessary debugging, >interoperability testing, security threat modeling, etc. that goes with >shipping an actual finished product. What that means for the HPC profile >work is that, come the end of August, Microsoft and possibly other >scheduler vendors/suppliers will need to lock down and start coding some >version of Web Services-based job scheduling and data transfer >protocols. If there is a fairly well-defined, feasible set of >specs/profile coming out of the GGF HPC working group (for recommendation >NOT yet for actual standards approval) that has some reasonable level of >consensus by then, then that's what Microsoft will very likely go >with. Otherwise Microsoft will need to defer the idea of shipping >anything that might be GGF compliant to version 3 of our product, which >will probably ship about 4 years from now. > > > >The chances of coming up with the bestHPC profile by the end of August are >slim. The chances of coming up with a fairly simple design that is good >enoughto cover the most important common cases by means of a relatively >simple, restricted form of extension seems much more feasible. Covering a >richer set of use cases would need to be deferred to a future version of >the profile, much in the manner that BES has been defined to cover an >important sub-category of use cases now, with a fuller EMS design being >done in parallel as future work. So I would argue that perhaps the most >important thing this design effort and the planned HPC profile working >group that will be set up in Tokyo can do is to identify what a good >enoughversion 1 HPC profile should be. > > > >Marvin. > > > > > >---------- >From: Carl Kesselman [mailto:carl@isi.edu] >Sent: Thursday, March 16, 2006 12:49 AM >To: Marvin Theimer >Cc: humphrey(a)cs.virginia.edu; ogsa-wg(a)ggf.org >Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > > > >Hi, > >In the interest of furthering agreement, I was not arguing that the >application had to be restartable. Rather, what has been shown to be >important is that the protocol be restartable in the following sense: if >you submit a job and the far and server fails, is the job running or not, >if you resubmit, do you get another job instance. The GT sumbission >protocol and Condor have a transactional semantics so that you can have at >most once submit semantics reegardless of client and server failures. The >fact that your application may be non-itempote is exactly why having a >well defined semantics in this case is important. > >So what is the next step? > >Carl > >Dr. Carl Kesselman email: carl(a)isi.edu >USC/Information Sciences Institute WWW: ><http://www.isi.edu/~carl>http://www.isi.edu/~carl >4676 Admiralty Way, Suite 1001 Phone: (310) 448-9338 >Marina del Rey, CA 90292-6695 Fax: (310) 823-6714 > > > >-----Original Message----- >From: Marvin Theimer <theimer(a)microsoft.com> >To: Carl Kesselman <carl(a)isi.edu> >CC: Marvin Theimer <theimer(a)microsoft.com>; Marty Humphrey ><humphrey(a)cs.virginia.edu>; ogsa-wg(a)ggf.org <ogsa-wg(a)ggf.org> >Sent: Wed Mar 15 14:26:36 2006 >Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > >Hi; > > > >I suspect that were mostly in agreement on things. In particular, I think >your list of four core aspects is a great starting point for a discussion >on the topic. > > > >I just replied to an earlier email from Ravi with a description of what Im >hoping to get out of examining various HPC use cases: > >· Identification of the simplest base case that everyone will have >to implement. > >· Identification of common cases we want to optimize. > >· Identification of how evolution and selective extension will work. > > > >I totally agree with you that the base use case I described isnt really a >griduse case. But it is an HPC use case in fact it is arguably the most >common use case in current existence. J So I think its important that we >understand how to seamlessly integrate and support that common and very >simple use case. > > > >I also totally agree with you that we cant let a solution to the simplest >HPC use case paint us into a corner that prevents supporting the richer >use cases that grid computing is all about. Thats why Id like to spend >significant effort exploring and understanding the issues of how to >support evolution and selective extension. In an ideal world a legacy >compute cluster job scheduler could have a simple grid shimthat let it >participate at a basic level, in a natural manner, in a grid environment, >while smarter clients and HPC services could interoperate with each other >in various selectively richer manners by means of extensions to the basic >HPC grid design. > > > >One place where I disagree with you is your assertion that everything >needs to be designed to be restartable. While thats a good goal to pursue >Im not convinced that you can achieve it in all cases. In particular, >there are at least two cases that I claim we want to support that arent >restartable: > >· We want to be able to run applications that arent restartable; >for example, because they perform non-idempotent operations on the >external physical environment. If such an application fails during >execution then the only one who can figure out what the proper next steps >are is the end user. > >· We want to be able to include (often-times legacy) systems that >arent fault tolerant, such as simple small compute clusters where the >owners didnt think that fault tolerance was worth paying for. > >Of course any acceptable design will have to enable systems that are fault >tolerant to export/expose that capability. To my mind its more a matter >of ensuring that non-fault-tolerant systems arent excluded from >participation in a grid. > > > >Other things we agree on: > >· We should certainly examine what remote job submission systems >do. We should certainly look at existing systems like Globus, Unicore, >and Legion. In general, we should be looking at everything that has any >actual experience that we can learn from and everything that is actually >deployed and hence represents a system that we potentially need to >interoperate with. (Whether a final design is actually able to >interoperate at any but the most basic level with various exotic existing >systems is a separate issue.) > >· We should absolutely focus on codifying what we know how to do >and avoid doing research as part of a standards process. I believe that >thinking carefully about how to support evolution and extension is our >best hope for allowing people to defer trying to bake their pet research >topic into standards since it provides a story for why todays standards >dont preclude tomorrows improvements. > > > >So I would propose that next steps are: > >· Continue to explore and classify various HPC use cases of various >differing levels of complexity. > >· Describe the requirements and limitations of existing job >scheduling and remote job submission systems. > >· Continue identifying and discussing key featuresof use cases and >potential design solutions, such as the four that you identified in your >last email. > > > >Marvin. > > > >________________________________ > >From: Carl Kesselman [<mailto:carl@isi.edu>mailto:carl@isi.edu] >Sent: Tuesday, March 14, 2006 7:50 AM >To: Marty Humphrey; ogsa-wg(a)ggf.org >Cc: Marvin Theimer >Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > > > >Hi, > > > >Just to be clear, Im not trying to suggest that the scope be expanded. I >agree with the approach of focusing on a baby step is a good one, and many >of the assumptions stated in Marvins list I am in total agreement with. >However, in taking baby steps I think that it is important that we end up >walking, and that in defining the use case, one can easily create >solutions that will not get you to the next step. This is my point about >looking at what we know how to do and have been doing in production >settings for many years now. In my mind, one of the scope grandness >problems has been that there has been far too little focus on codifying >what we know how to do in favor of using a standards process as an excuse >to design new things. So at the risk of sounding partisan, the simplified >use case that Marvin is proposing is exactly the use case that GRAM has >been doing for over ten years now (I think the same can be said about >UNICORE and Legion). > > > >So let me try to be constructive. One of the things that falls out of >Marvins list could be a set of basic concepts/operations that need to be >defined. These include: > >1) A way of describing localjob configuration, i.e. where to find the >executable, data files, etc. This should be very conservative with its >assumptions on shared file systems and accessibility. In general, what >needs to be stated here are what are the underlying aspects of the >underlying resource that are exposed to the outward facing interface. > >2) A way of naming a submission point (should probably have a way of >modeling queues). > >3) A core set of job management operations, submit, status, kill. These >need to be defined in such a way at to be tolerate to a variety of failure >scenarios, in that the state needs to be well defined in the case of failure. > >4) A state model that one can use to describe what is going on with the >jobs and a way to access that state. Can be simple (queued, running, >done), may need to be extensible. One can view the accounting information >as being exposed > > > >So, one thing to do would be to agree that these are (or are not) the >right four things that need to be defined and if so, start to flesh out >these in a way that supports the core use case but doesnt introduce >assumptions that would preclude more complex use cases in the future. > > > > > >Carl > > > >________________________________ > >From: owner-ogsa-wg(a)ggf.org >[<mailto:owner-ogsa-wg@ggf.org>mailto:owner-ogsa-wg@ggf.org] On Behalf Of >Marty Humphrey >Sent: Tuesday, March 14, 2006 6:32 AM >To: ogsa-wg(a)ggf.org >Cc: 'Marvin Theimer' >Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > > > >Carl, > > > >Your comments are very important. We would love to have your active >participation in this effort. Your experience is, of course, matched by few! > > > >I re-emphasize that this represents (my words, not anyone elses) baby >stepsthat are necessary and important for the Grid community. In my >opinion, the biggest challenge will be to fight the urge to expand the >scope beyond a small size. You cannot ignore the possibility that the GGF >has NOT made as much progress as it should have to date. Furthermore, one >such plausible explanation is that the scope is too grand. > > > >-- Marty > > > > > >________________________________ > >From: owner-ogsa-wg(a)ggf.org >[<mailto:owner-ogsa-wg@ggf.org>mailto:owner-ogsa-wg@ggf.org] On Behalf Of >Carl Kesselman >Sent: Tuesday, March 14, 2006 8:47 AM >To: Marvin Theimer; Ian Foster; ogsa-wg(a)ggf.org >Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > > > >Hi, > > > >While I have no wish to engage in the what is a Gridargument, there are >some elements of your base use case that I would be concerned >about. Specifically, the assumption that the submission in into a local >clusteron which there is an existing account may lead one to a solution >that may not generalize to the solution to the case of submission across >autonomous policy domains. I would also argue that ignoring issues of >fault tolerance from the beginning is also problematic. One must at least >design operations that are restartable (for example at most once >submission semantics). > > > >I would finally suggest that while examining existing job schedule systems >is a good thing to do, we should also examine existing remote submission >systems (dare I say Grid systems). The basic HPC use case is one in which >there is a significant amount implementation and usage experience. > > > >Thanks, > > >Carl > > > > > >________________________________ > >From: owner-ogsa-wg(a)ggf.org >[<mailto:owner-ogsa-wg@ggf.org>mailto:owner-ogsa-wg@ggf.org] On Behalf Of >Marvin Theimer >Sent: Monday, March 13, 2006 2:42 PM >To: Ian Foster; ogsa-wg(a)ggf.org >Cc: Marvin Theimer >Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > > > >Hi; > > > >Ian, you are correct that I view job submission to a cluster as being one >of the simplest, and hence most basic, HPC use cases to start with. Or, >to be slightly more general, I view job submission to a black boxthat can >run jobs be it a cluster or an SMP or an SGI NUMA machine or what-have-you >as being the simplest and hence most basic HPC use case to start >with. The key distinction for me is that the internals of the boxare for >the most part not visible to the client, at least as far as submitting and >running compute jobs is concerned. There may well be a separate interface >for dealing with things like system management, but I want to explicitly >separate those things out in order to allow for use of boxesthat might be >managed by proprietary means or by means obeying standards that a >particular job submission client is unfamiliar with. > > > >I think the use case that Ravi Subramaniam posted to this mailing list >back on 2/17 is a good one to start a discussion around. However, Id like >to present it from a different point-of-view than he did. The manner in >which the use case is currently presented emphasizes all the capabilities >and services needed to handle the fully general case of submitting a batch >job to a computing utility/service. Thats a great way of producing a >taxonomy against which any given system or design can be compared to see >what it has to offer. I would argue that the next step is to ask whats >the simplest subset that represents a useful system/design and how should >one categorize the various capabilities and services he has identified so >as to arrive at meaningful components that can be selectively used to >obtain progressively more capable systems. > > > >Another useful exercise to do is to examine existing job scheduling >systems in order to understand what they provide. Since in the real world >we will have to deal with the legacy of existing systems it will be >important to understand how they relate to the use cases we explore. In >the same vein, it will be important to take into account and understand >other existing infrastructures that people use that are related to HPC use >cases. Im thinking of things like security infrastructures, directory >services, and so forth. From the point-of-view of managing complexity and >reducing total-cost-of-ownership, it will be important to understand the >extent to which existing infrastructure and services can be reused rather >than reinvented. > > > >To kick off a discussion around the topic of a minimalist HPC use case, I >present a straw man description of such below and then present a first >attempt at categorizing various areas of extension. The categorization of >extension areas is not meant to be complete or even all that carefully >thought-out as far as componentization boundaries are concerned; it is >merely meant to be a first contribution to get the discussion going. > > > >A basic HPC use case: Compute cluster embedded within an organization. > >· This is your basic batch job scheduling scenario. Only a very basic >state transition diagram is visible to the client, with the following >states for a job: queued, running, finished. Additional states -- and >associated state transition request operations and functionality -- are >not supported. Examples of additional states and associated functionality >include suspension of jobs and migration of jobs. > >· Only "standard" resources can be described, for example: number of >cpus/nodes needed, memory requirements, disk requirements, etc. (think >resources that are describable by JSDL). > >· Once a job has been submitted it can be cancelled, but its resource >requests can't be modified. > >· A distributed file system is accessible from client desktop machines >and client file servers, as well as compute nodes of the compute >cluster. This implies that no data staging is required, that programs can >be (for the most part) executed from existing file system locations, and >that no program "provisioning" is required (since you can execute them >from wherever they are already installed). Thus in this use case all data >transfer and program installation operations are the responsibility of the >user. > >· Users already have accounts within the existing security >infrastructure (e.g. Kerberos). They would like to use these and not have >to create/manage additional authentication/authorization credentials (at >least at the level that is visible to them). > >· The job scheduling service resides at a well-known network name and >it is aware of the compute cluster and its resources by "private" means >(e.g. it runs on the head node of the cluster and employs private means to >monitor and control the resources of the cluster). This implies that >there is no need for any sort of directory services for finding the >compute cluster or the resources it represents other than basic DNS. > >· Compute cluster system management is opaque to users and is the >concern of the compute cluster's owners. This implies that system >management is not part of the compute cluster's public job scheduling >interface. This also implies that there is no need for a logging >interface to the service. I assume that application-level logging can be >done by means of libraries that write to client files; i.e. that there is >no need for any sort of special system support for logging. > >· A simple polling-based interface is the simplest form of interface >to something like a job scheduling service. However, a simple call-back >notification interface is a very useful addition that potentially provides >substantial performance benefits since it can enable the avoidance of lots >of unnecessary network traffic. Only job state changes result in >notification messages. > >· There are no notions of fault tolerance. Jobs that fail must be >resubmitted by the client. Neither the cluster head node nor its compute >nodes are fault tolerant. I do expect the client software to return an >indication of failure-due-system-fault when appropriate. (Note that this >may also occur when things like network partitions occur.) > >· One does need some notion of how to deal with orphaned resources and >jobs. The notion of job lifetime and post-expiration garbage collection >is a natural approach here. > >· The scheduling service provides a fixed set of scheduling policies, >with only a few basic choices (or maybe even just one), such as FIFO or >round-robin. There is no notion, in general, of SLAs (which are a form of >scheduling policy). > >· Enough information must be returned to the client when a job >finishes to enable basic accounting functionality. This means things like >total wall-clock time the job ran and a summary of resources used. There >is not a need for the interface to support any sort of grouping of >accounting information. That is, jobs do not need to be associated with >projects, groups, or other accounting entities and the job scheduling >service is not responsible for tracking accounting information across such >entities. As long as basic resource utilization information is returnable >for each job, accounting can be done externally to the job scheduling >service. I do assume that jobs can be uniquely identified by some means >and can be uniquely associated with some principal entity existing in the >overall system, such as a user name. > >· Just as there is no notion of requiring the job scheduling service >to track any but the most basic job-level accounting information, there is >no notion of the service enforcing quotas on jobs. > >· Although it is generally useful to separate the notions of resource >reservation from resource usage (e.g. to enable interactive and debugging >use of resources), it is not a necessity for the most basic of job >scheduling services. > >· There is no notion of tying multiple jobs together, either to >support things like dependency graphs or to support things like >workflows. Such capabilities must be implemented by clients of the job >scheduling service. > > > >Interesting extension areas: > >· Additional scheduling policies > >o Weighted fair-share, & > >o Multiple queues > >o SLAs > >o ... > >· Extended resource descriptions > >o Additional resource types, such as GPUs > >o Additional types of compute resources, such as desktop computers > >o Condor-style class ads > >· Extended job descriptions (as returned to requesting clients and >sys admins) > >· Additional classes of security credentials > >· Reservations separated from execution > >o Enabling interactive and debugging jobs > >o Support for multiple competing schedulers (incl. desktop cycle >stealing and market-based approaches to scheduling compute resources) > >· Ability to modify jobs during their existence > >· Fault tolerance > >o Automatic rescheduling of jobs that failed due to system faults > >o Highly available resources: This is partly a policy statement by a >scheduling service about its characteristics and partly the ability to >rebind clients to migrated service endpoints > >· Extended state transition diagrams and associated functionalities > >o Job suspension > >o Job migration > >o & > >· Accounting & quotas > >· Operating on arrays of jobs > >· Meta-schedulers, multiple schedulers, and ecologies and hierarchies >of multiple schedulers > >o Meta-schedulers > >· Hierarchical job scheduling with a meta-scheduler as the only entry >point; forwarding jobs to the meta-scheduler from other subsidiary schedulers > >o Condor-style matchmaking > >· Directory services > >o Using existing directory services > >o Abstract directory service interface(s) > >· Data transfer topics > >o Application data staging > >· Naming > >· Efficiency > >· Convenience > >· Cleanup > >o Program staging/provisioning > >· Description > >· Installation > >· Cleanup > > > > > >Marvin. > > > >________________________________ > >From: Ian Foster [<mailto:foster@mcs.anl.gov>mailto:foster@mcs.anl.gov] >Sent: Monday, February 20, 2006 9:20 AM >To: Marvin Theimer; ogsa-wg(a)ggf.org >Cc: Marvin Theimer; Savas Parastatidis; Tony Hey; Marty Humphrey; >gcf(a)grids.ucs.indiana.edu >Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" > > > >Dear All: > >The most important thing to understand at this point (IMHO) is the scope >of this "HPC use case," as this will determine just how minimal we can be. > >I get the impression that the principal goal may be "job submission to a >cluster." Is that correct? How do we start to circumscribe the scope more >explicitly? > >Ian. > > > >At 05:45 AM 2/16/2006 -0800, Marvin Theimer wrote: > >Enclosed is a paper that advocates an additional set of activities that >the authors believe that the OGSA working groups should engage in. > > > >Broadly speaking, the OGSA and related working groups are already doing a >bunch of important things: > >· There is broad exploration of the big picture, including >enumeration of use cases, taxonomy of areas, identification of research >issues, etc. > >· There is work going on in each of the horizontal areas that have >been identified, such as EMS, data services, etc. > >· There is working going around individual specifications, such as >BES, JSDL, etc. > > > >Given that individual specifications are beginning to come to fruition, >the authors believe it is time to also start defining vertical >profilesthat precisely describe how groups of individual specifications >should be employed to implement specific use cases in an interoperable >manner. The authors also believe that the process of defining these >profiles offers an opportunity to close the design loopby relating the >various on-going protocol and standards efforts back to the use cases in a >very concrete manner. This provides an end-to-end setting in which to >identify holes and issues that might require additional protocols and/or >(incremental) changes to existing protocols. The paper introduces both >the general notion of doing focused vertical design effortsand then >focuses on a specific vertical design effort, namely a minimal HPC design. > > > >The paper derives a specific HPC design in a first principlesmanner since >the authors believe that this increases the chances of identifying >issues. As a consequence, existing specifications and the activities of >existing working groups are not mentioned and this paper is not an attempt >to actually define a specifications profile. Also, the absence of >references to existing work is not meant to imply that such work is in any >way irrelevant or inappropriate. The paper should be viewed as a first >abstract attempt to propose a new kind of activity within OGSA. The >expectation is that future open discussions and publications will explore >the concrete details of such a proposal. > > > >This paper was recently sent to a few key individuals in order to get >feedback from them before submitting it to the wider GGF >community. Unfortunately that process took longer than intended and some >members of the community may have already seen a copy of the paper without >knowing the context within it was written. This email should hopefully >dispel any misconceptions that may have occurred. > > > >For those people who will be around on for the F2F meetings on Friday, >Marvin Theimer will be giving a talk on the contents of this paper at a >time and place to be announced. > > > >Marvin Theimer, Savas Parastatidis, Tony Hey, Marty Humphrey, Geoffrey Fox > > > >_______________________________________________________________ >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 > <<http://www.globus.org/>http://www.globus.org/> _______________________________________________________________ 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

4 5

NO call on this Wednesday (March 22)
by Hiro Kishimoto 22 Mar '06

22 Mar '06

Hi all, I've talked with Takuya and decided to postpone "security architecture" discussion to next Wednesday (March 29). Given that security is the only agenda item for this Wednesday, I propose we have NO call on March 22. <NEXT CALL> March 27 (Mon): EMS scenarios, Steven's scenarios review, Information Model (Ellen's CIM profile review) March 29 (Wed): Security Architecture (Takuya and Frank) F2F preparation, Joint CDDLM discussion April 3 (Mon): NO call April 4-7: F2F meeting in San Francisco Bay Area Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

Minutes from telecon 3/20 uploaded
by Treadwell, Jem 21 Mar '06

21 Mar '06

Hi, The minutes from Monday's telecon are now available on GridForge at http://tinyurl.com/nbeso. - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com>

1 0

RE: [ogsa-wg] Webcast thoughts
by Treadwell, Jem 20 Mar '06

20 Mar '06

Hi Andrew, sorry for the delayed response... for anyone wondering what this is about, we're proposing to do a public webcast about OGSA, in the April timeframe, and will have more details once the logistics have firmed up a little more. HP will host. I've been working on the slides as a background activity, so please assume I have the pen at the moment. I agree that they need augmenting for this. I think we can set our own expectations for the audience - we can say who it's for when we advertise it. As a starting point I assume we want to pitch it in the middle - some background, but also some specifics on the capabilities and where things fit. Thoughts for an outline; some of this is already in place, of course: * Background to grid and GGF, including some history & definitions * Where grid is being used now, importance in the commercial world, and the future * Transition to SOA & Web services - why, and what it means * Standards - why they're important, a review of relevant standards and SDOs, including latest news * Some specifics about OGSA: background, some info from the Roadmap, and an explanation of profiles * Details of the OGSA capabilities and closely-related work - an intro diagram and a few slides on each - high-level intro, some detailed examples, status of work - we need to agree how technical we want to get, and try to keep all at the same level. e.g.: * Infrastructure * Security * EMS * Data * Resource Mgmt * Info * CDDLM * Self mgmt * WS-Agreement * Naming * Any others? BUT: we will have to be conscious of time: I've already listed too much if capabilities average more than 3 minutes. So this is probably overly ambitious. Although we talked earlier about a 2-hour slot, I now know it's actually 90 minutes. [We'll have 30 minutes before the start for the presenters to get online and do logistics.] So the target for the presentation should be one hour, with the remainder for Q&A. Some time will be spent on preliminaries, so Q&A will probably be down to 20 mins. We probably won't have time to do audience polls, other than maybe one at the end while Q&A is in progress. Here are a few other things we'll need to provide ahead of time: * Title of presentation (e.g. "Defining the Grid: An Overview of OGSA") * Short abstract of session * Names of speaker(s) * Duration: Target one hour for presentation, 30 minutes for Q&A * Short bios for the speaker(s) -- two or three sentences each - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com> ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andrew Grimshaw Sent: Wednesday, March 15, 2006 10:22 AM To: 'ogsa-wg' Subject: [ogsa-wg] Webcast thoughts All, I'd like to start an email discussion in advance of the F2F on the webcast content. While we do have an initial set of slides - I think we need to make sure that we design the talk for our expected audience - rather than based on the material we already have in the deck. When Dave I went to MS our slide deck was not technical enough - we had the wrong talk with us, and so had to improvise. So, one of the things I'd like to know is: Who is our expected audience? Is it technical people, if so, are they web services aware?, are they applications developers? Or are they mostly managers and planners. Or do we have to try and make everyone happy. Any insight? A Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

1 0

Proposed agenda for March 20th call
by Hiro Kishimoto 20 Mar '06

20 Mar '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 20th Monday from 4pm to 6pm (CST). The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0320 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (March 15th) Thanks Mark! https://forge.gridforum.org/projects/ogsa-wg/document/minutes-2006-03-15 Agenda bashing 2) HP/IBM/Intel/Microsoft white paper Q&A (30 min, time boxed) 4 companies publish their roadmap for reconciliation of the web services management standards. Heather gave us brief overview on March 15 call. We agree to read this white paper and come back to discuss with Heather. http://www-128.ibm.com/developerworks/webservices/library/specification/ws-… 3) OGSA HPC profile discussion (60 min) Marvin will lead HPC profile discussion. - HPC usecases discussions - functionalities and existing specifications - GGF17 charter BoF plan Marvin's proposal; https://forge.gridforum.org/projects/ogsa-wg/document/GGF16-F2F-Evolutionar… https://forge.gridforum.org/projects/ogsa-wg/document/An_Evolutionary_Appro… 4) April F2F and GGF17 session update (30 min) F2F venues are Fujitsu and Intel Suggested accommodation is "St. Francis Arms." It is sister hotel of "Corporate Inn" and nearby location. Proposed agenda is now uploaded to GridForge https://forge.gridforum.org/projects/ogsa-wg/document/2006Apr-OGSA-F2F-agen… Since GGF17 session request deadline was last Friday. I've booked tentatively two workshop sessions for EMS and Info model. I would have open discussion and finalize our sessions detail based on the discussion. 5) Wrap up (10 min) AOB <NEXT CALL> March 22 (Wed): Security Architecture (Takuya and Frank) March 27 (Mon): EMS scenarios, Steven's scenarios review, Information Model, Ellen's CIM profile review March 29 (Wed): F2F preparation, joint CDDLM discussion April 3 (Mon): NO call April 4-7: F2F meeting in San Francisco Bay Area Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Carl Kesselman 16 Mar '06

16 Mar '06

Hmm, I probably shouldn't send long messages from my blackberry. Hopefully, you can get through the typos and get my point. Carl Dr. Carl Kesselman email: carl(a)isi.edu USC/Information Sciences Institute WWW: http://www.isi.edu/~carl 4676 Admiralty Way, Suite 1001 Phone: (310) 448-9338 Marina del Rey, CA 90292-6695 Fax: (310) 823-6714 ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Carl Kesselman Sent: Thursday, March 16, 2006 12:49 AM To: theimer(a)microsoft.com Cc: humphrey(a)cs.virginia.edu; ogsa-wg(a)ggf.org Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Hi, In the interest of furthering agreement, I was not arguing that the application had to be restartable. Rather, what has been shown to be important is that the protocol be restartable in the following sense: if you submit a job and the far and server fails, is the job running or not, if you resubmit, do you get another job instance. The GT sumbission protocol and Condor have a transactional semantics so that you can have at most once submit semantics reegardless of client and server failures. The fact that your application may be non-itempote is exactly why having a well defined semantics in this case is important. So what is the next step? Carl Dr. Carl Kesselman email: carl(a)isi.edu USC/Information Sciences Institute WWW: http://www.isi.edu/~carl 4676 Admiralty Way, Suite 1001 Phone: (310) 448-9338 Marina del Rey, CA 90292-6695 Fax: (310) 823-6714 -----Original Message----- From: Marvin Theimer <theimer(a)microsoft.com> To: Carl Kesselman <carl(a)isi.edu> CC: Marvin Theimer <theimer(a)microsoft.com>; Marty Humphrey <humphrey(a)cs.virginia.edu>; ogsa-wg(a)ggf.org <ogsa-wg(a)ggf.org> Sent: Wed Mar 15 14:26:36 2006 Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Hi; I suspect that we're mostly in agreement on things. In particular, I think your list of four core aspects is a great starting point for a discussion on the topic. I just replied to an earlier email from Ravi with a description of what I'm hoping to get out of examining various HPC use cases: * Identification of the simplest base case that everyone will have to implement. * Identification of common cases we want to optimize. * Identification of how evolution and selective extension will work. I totally agree with you that the base use case I described isn't really a "grid" use case. But it is an HPC use case - in fact it is arguably the most common use case in current existence. J So I think it's important that we understand how to seamlessly integrate and support that common - and very simple - use case. I also totally agree with you that we can't let a solution to the simplest HPC use case paint us into a corner that prevents supporting the richer use cases that grid computing is all about. That's why I'd like to spend significant effort exploring and understanding the issues of how to support evolution and selective extension. In an ideal world a legacy compute cluster job scheduler could have a simple "grid shim" that let it participate at a basic level, in a natural manner, in a grid environment, while smarter clients and HPC services could interoperate with each other in various selectively richer manners by means of extensions to the basic HPC grid design. One place where I disagree with you is your assertion that everything needs to be designed to be restartable. While that's a good goal to pursue I'm not convinced that you can achieve it in all cases. In particular, there are at least two cases that I claim we want to support that aren't restartable: * We want to be able to run applications that aren't restartable; for example, because they perform non-idempotent operations on the external physical environment. If such an application fails during execution then the only one who can figure out what the proper next steps are is the end user. * We want to be able to include (often-times legacy) systems that aren't fault tolerant, such as simple small compute clusters where the owners didn't think that fault tolerance was worth paying for. Of course any acceptable design will have to enable systems that are fault tolerant to export/expose that capability. To my mind it's more a matter of ensuring that non-fault-tolerant systems aren't excluded from participation in a grid. Other things we agree on: * We should certainly examine what remote job submission systems do. We should certainly look at existing systems like Globus, Unicore, and Legion. In general, we should be looking at everything that has any actual experience that we can learn from and everything that is actually deployed and hence represents a system that we potentially need to interoperate with. (Whether a final design is actually able to interoperate at any but the most basic level with various exotic existing systems is a separate issue.) * We should absolutely focus on codifying what we know how to do and avoid doing research as part of a standards process. I believe that thinking carefully about how to support evolution and extension is our best hope for allowing people to defer trying to bake their pet research topic into standards since it provides a story for why today's standards don't preclude tomorrow's improvements. So I would propose that next steps are: * Continue to explore and classify various HPC use cases of various differing levels of complexity. * Describe the requirements - and limitations - of existing job scheduling and remote job submission systems. * Continue identifying and discussing key "features" of use cases and potential design solutions, such as the four that you identified in your last email. Marvin. ________________________________ From: Carl Kesselman [mailto:carl@isi.edu] Sent: Tuesday, March 14, 2006 7:50 AM To: Marty Humphrey; ogsa-wg(a)ggf.org Cc: Marvin Theimer Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Hi, Just to be clear, I'm not trying to suggest that the scope be expanded. I agree with the approach of focusing on a baby step is a good one, and many of the assumptions stated in Marvin's list I am in total agreement with. However, in taking baby steps I think that it is important that we end up walking, and that in defining the use case, one can easily create solutions that will not get you to the next step. This is my point about looking at what we know how to do and have been doing in production settings for many years now. In my mind, one of the scope grandness problems has been that there has been far too little focus on codifying what we know how to do in favor of using a standards process as an excuse to design new things. So at the risk of sounding partisan, the simplified use case that Marvin is proposing is exactly the use case that GRAM has been doing for over ten years now (I think the same can be said about UNICORE and Legion). So let me try to be constructive. One of the things that falls out of Marvin's list could be a set of basic concepts/operations that need to be defined. These include: 1) A way of describing "local" job configuration, i.e. where to find the executable, data files, etc. This should be very conservative with its assumptions on shared file systems and accessibility. In general, what needs to be stated here are what are the underlying aspects of the underlying resource that are exposed to the outward facing interface. 2) A way of naming a submission point (should probably have a way of modeling queues). 3) A core set of job management operations, submit, status, kill. These need to be defined in such a way at to be tolerate to a variety of failure scenarios, in that the state needs to be well defined in the case of failure. 4) A state model that one can use to describe what is going on with the jobs and a way to access that state. Can be simple (queued, running, done), may need to be extensible. One can view the accounting information as being exposed So, one thing to do would be to agree that these are (or are not) the right four things that need to be defined and if so, start to flesh out these in a way that supports the core use case but doesn't introduce assumptions that would preclude more complex use cases in the future. Carl ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marty Humphrey Sent: Tuesday, March 14, 2006 6:32 AM To: ogsa-wg(a)ggf.org Cc: 'Marvin Theimer' Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Carl, Your comments are very important. We would love to have your active participation in this effort. Your experience is, of course, matched by few! I re-emphasize that this represents (my words, not anyone else's) "baby steps" that are necessary and important for the Grid community. In my opinion, the biggest challenge will be to fight the urge to expand the scope beyond a small size. You cannot ignore the possibility that the GGF has NOT made as much progress as it should have to date. Furthermore, one such plausible explanation is that the scope is too grand. -- Marty ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Carl Kesselman Sent: Tuesday, March 14, 2006 8:47 AM To: Marvin Theimer; Ian Foster; ogsa-wg(a)ggf.org Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Hi, While I have no wish to engage in the "what is a Grid" argument, there are some elements of your base use case that I would be concerned about. Specifically, the assumption that the submission in into a "local cluster" on which there is an existing account may lead one to a solution that may not generalize to the solution to the case of submission across autonomous policy domains. I would also argue that ignoring issues of fault tolerance from the beginning is also problematic. One must at least design operations that are restartable (for example at most once submission semantics). I would finally suggest that while examining existing job schedule systems is a good thing to do, we should also examine existing remote submission systems (dare I say Grid systems). The basic HPC use case is one in which there is a significant amount implementation and usage experience. Thanks, Carl ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marvin Theimer Sent: Monday, March 13, 2006 2:42 PM To: Ian Foster; ogsa-wg(a)ggf.org Cc: Marvin Theimer Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Hi; Ian, you are correct that I view job submission to a cluster as being one of the simplest, and hence most basic, HPC use cases to start with. Or, to be slightly more general, I view job submission to a "black box" that can run jobs - be it a cluster or an SMP or an SGI NUMA machine or what-have-you - as being the simplest and hence most basic HPC use case to start with. The key distinction for me is that the internals of the "box" are for the most part not visible to the client, at least as far as submitting and running compute jobs is concerned. There may well be a separate interface for dealing with things like system management, but I want to explicitly separate those things out in order to allow for use of "boxes" that might be managed by proprietary means or by means obeying standards that a particular job submission client is unfamiliar with. I think the use case that Ravi Subramaniam posted to this mailing list back on 2/17 is a good one to start a discussion around. However, I'd like to present it from a different point-of-view than he did. The manner in which the use case is currently presented emphasizes all the capabilities and services needed to handle the fully general case of submitting a batch job to a computing utility/service. That's a great way of producing a taxonomy against which any given system or design can be compared to see what it has to offer. I would argue that the next step is to ask what's the simplest subset that represents a useful system/design and how should one categorize the various capabilities and services he has identified so as to arrive at meaningful components that can be selectively used to obtain progressively more capable systems. Another useful exercise to do is to examine existing job scheduling systems in order to understand what they provide. Since in the real world we will have to deal with the legacy of existing systems it will be important to understand how they relate to the use cases we explore. In the same vein, it will be important to take into account and understand other existing infrastructures that people use that are related to HPC use cases. I'm thinking of things like security infrastructures, directory services, and so forth. From the point-of-view of managing complexity and reducing total-cost-of-ownership, it will be important to understand the extent to which existing infrastructure and services can be reused rather than reinvented. To kick off a discussion around the topic of a minimalist HPC use case, I present a straw man description of such below and then present a first attempt at categorizing various areas of extension. The categorization of extension areas is not meant to be complete or even all that carefully thought-out as far as componentization boundaries are concerned; it is merely meant to be a first contribution to get the discussion going. A basic HPC use case: Compute cluster embedded within an organization. * This is your basic batch job scheduling scenario. Only a very basic state transition diagram is visible to the client, with the following states for a job: queued, running, finished. Additional states -- and associated state transition request operations and functionality -- are not supported. Examples of additional states and associated functionality include suspension of jobs and migration of jobs. * Only "standard" resources can be described, for example: number of cpus/nodes needed, memory requirements, disk requirements, etc. (think resources that are describable by JSDL). * Once a job has been submitted it can be cancelled, but its resource requests can't be modified. * A distributed file system is accessible from client desktop machines and client file servers, as well as compute nodes of the compute cluster. This implies that no data staging is required, that programs can be (for the most part) executed from existing file system locations, and that no program "provisioning" is required (since you can execute them from wherever they are already installed). Thus in this use case all data transfer and program installation operations are the responsibility of the user. * Users already have accounts within the existing security infrastructure (e.g. Kerberos). They would like to use these and not have to create/manage additional authentication/authorization credentials (at least at the level that is visible to them). * The job scheduling service resides at a well-known network name and it is aware of the compute cluster and its resources by "private" means (e.g. it runs on the head node of the cluster and employs private means to monitor and control the resources of the cluster). This implies that there is no need for any sort of directory services for finding the compute cluster or the resources it represents other than basic DNS. * Compute cluster system management is opaque to users and is the concern of the compute cluster's owners. This implies that system management is not part of the compute cluster's public job scheduling interface. This also implies that there is no need for a logging interface to the service. I assume that application-level logging can be done by means of libraries that write to client files; i.e. that there is no need for any sort of special system support for logging. * A simple polling-based interface is the simplest form of interface to something like a job scheduling service. However, a simple call-back notification interface is a very useful addition that potentially provides substantial performance benefits since it can enable the avoidance of lots of unnecessary network traffic. Only job state changes result in notification messages. * There are no notions of fault tolerance. Jobs that fail must be resubmitted by the client. Neither the cluster head node nor its compute nodes are fault tolerant. I do expect the client software to return an indication of failure-due-system-fault when appropriate. (Note that this may also occur when things like network partitions occur.) * One does need some notion of how to deal with orphaned resources and jobs. The notion of job lifetime and post-expiration garbage collection is a natural approach here. * The scheduling service provides a fixed set of scheduling policies, with only a few basic choices (or maybe even just one), such as FIFO or round-robin. There is no notion, in general, of SLAs (which are a form of scheduling policy). * Enough information must be returned to the client when a job finishes to enable basic accounting functionality. This means things like total wall-clock time the job ran and a summary of resources used. There is not a need for the interface to support any sort of grouping of accounting information. That is, jobs do not need to be associated with projects, groups, or other accounting entities and the job scheduling service is not responsible for tracking accounting information across such entities. As long as basic resource utilization information is returnable for each job, accounting can be done externally to the job scheduling service. I do assume that jobs can be uniquely identified by some means and can be uniquely associated with some principal entity existing in the overall system, such as a user name. * Just as there is no notion of requiring the job scheduling service to track any but the most basic job-level accounting information, there is no notion of the service enforcing quotas on jobs. * Although it is generally useful to separate the notions of resource reservation from resource usage (e.g. to enable interactive and debugging use of resources), it is not a necessity for the most basic of job scheduling services. * There is no notion of tying multiple jobs together, either to support things like dependency graphs or to support things like workflows. Such capabilities must be implemented by clients of the job scheduling service. Interesting extension areas: * Additional scheduling policies o Weighted fair-share, ... o Multiple queues o SLAs o ... * Extended resource descriptions o Additional resource types, such as GPUs o Additional types of compute resources, such as desktop computers o Condor-style class ads * Extended job descriptions (as returned to requesting clients and sys admins) * Additional classes of security credentials * Reservations separated from execution o Enabling interactive and debugging jobs o Support for multiple competing schedulers (incl. desktop cycle stealing and market-based approaches to scheduling compute resources) * Ability to modify jobs during their existence * Fault tolerance o Automatic rescheduling of jobs that failed due to system faults o Highly available resources: This is partly a policy statement by a scheduling service about its characteristics and partly the ability to rebind clients to migrated service endpoints * Extended state transition diagrams and associated functionalities o Job suspension o Job migration o ... * Accounting & quotas * Operating on arrays of jobs * Meta-schedulers, multiple schedulers, and ecologies and hierarchies of multiple schedulers o Meta-schedulers * Hierarchical job scheduling with a meta-scheduler as the only entry point; forwarding jobs to the meta-scheduler from other subsidiary schedulers o Condor-style matchmaking * Directory services o Using existing directory services o Abstract directory service interface(s) * Data transfer topics o Application data staging * Naming * Efficiency * Convenience * Cleanup o Program staging/provisioning * Description * Installation * Cleanup Marvin. ________________________________ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Monday, February 20, 2006 9:20 AM To: Marvin Theimer; ogsa-wg(a)ggf.org Cc: Marvin Theimer; Savas Parastatidis; Tony Hey; Marty Humphrey; gcf(a)grids.ucs.indiana.edu Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Dear All: The most important thing to understand at this point (IMHO) is the scope of this "HPC use case," as this will determine just how minimal we can be. I get the impression that the principal goal may be "job submission to a cluster." Is that correct? How do we start to circumscribe the scope more explicitly? Ian. At 05:45 AM 2/16/2006 -0800, Marvin Theimer wrote: Enclosed is a paper that advocates an additional set of activities that the authors believe that the OGSA working groups should engage in. Broadly speaking, the OGSA and related working groups are already doing a bunch of important things: * There is broad exploration of the big picture, including enumeration of use cases, taxonomy of areas, identification of research issues, etc. * There is work going on in each of the horizontal areas that have been identified, such as EMS, data services, etc. * There is working going around individual specifications, such as BES, JSDL, etc. Given that individual specifications are beginning to come to fruition, the authors believe it is time to also start defining vertical profilesthat precisely describe how groups of individual specifications should be employed to implement specific use cases in an interoperable manner. The authors also believe that the process of defining these profiles offers an opportunity to close the design loopby relating the various on-going protocol and standards efforts back to the use cases in a very concrete manner. This provides an end-to-end setting in which to identify holes and issues that might require additional protocols and/or (incremental) changes to existing protocols. The paper introduces both the general notion of doing focused vertical design effortsand then focuses on a specific vertical design effort, namely a minimal HPC design. The paper derives a specific HPC design in a first principlesmanner since the authors believe that this increases the chances of identifying issues. As a consequence, existing specifications and the activities of existing working groups are not mentioned and this paper is not an attempt to actually define a specifications profile. Also, the absence of references to existing work is not meant to imply that such work is in any way irrelevant or inappropriate. The paper should be viewed as a first abstract attempt to propose a new kind of activity within OGSA. The expectation is that future open discussions and publications will explore the concrete details of such a proposal. This paper was recently sent to a few key individuals in order to get feedback from them before submitting it to the wider GGF community. Unfortunately that process took longer than intended and some members of the community may have already seen a copy of the paper without knowing the context within it was written. This email should hopefully dispel any misconceptions that may have occurred. For those people who will be around on for the F2F meetings on Friday, Marvin Theimer will be giving a talk on the contents of this paper at a time and place to be announced. Marvin Theimer, Savas Parastatidis, Tony Hey, Marty Humphrey, Geoffrey Fox _______________________________________________________________ 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 <http://www.globus.org/>

1 0

HP/IBM/Intel/MSFT roadmap
by Hiro Kishimoto 16 Mar '06

16 Mar '06

Hi all, We need to know what they say; "Web services management standards convergence announcement" http://devresource.hp.com/drc/specifications/wsm/index.jsp -- Hiro Kishimoto

3 2

formatdb man page
by Christopher Smith 15 Mar '06

15 Mar '06

Here is a link to the man page for formatdb. http://bioinformatics.ubc.ca/resources/tools/?name=formatdb The important options to note are the one to choose whether it's a protein or a nucleotide database, and the other is to generate indices or not. A typical invocation, given a protein database in FASTA format called ecoli.aa that I want indices for, I run: formatdb -i ecoli.aa -p T -o T and the resulting files will be generated: ecoli.aa.phr ecoli.aa.pin ecoli.aa.pnd ecoli.aa.pni ecoli.aa.psd ecoli.aa.psi ecoli.aa.psq And in the blastall command I reference the database named 'ecoli.aa'. By the way ... many people just deploy the generated files. -- Chris

1 0

RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Carl Kesselman 15 Mar '06

15 Mar '06

Hi, Just to be clear, I'm not trying to suggest that the scope be expanded. I agree with the approach of focusing on a baby step is a good one, and many of the assumptions stated in Marvin's list I am in total agreement with. However, in taking baby steps I think that it is important that we end up walking, and that in defining the use case, one can easily create solutions that will not get you to the next step. This is my point about looking at what we know how to do and have been doing in production settings for many years now. In my mind, one of the scope grandness problems has been that there has been far too little focus on codifying what we know how to do in favor of using a standards process as an excuse to design new things. So at the risk of sounding partisan, the simplified use case that Marvin is proposing is exactly the use case that GRAM has been doing for over ten years now (I think the same can be said about UNICORE and Legion). So let me try to be constructive. One of the things that falls out of Marvin's list could be a set of basic concepts/operations that need to be defined. These include: 1) A way of describing "local" job configuration, i.e. where to find the executable, data files, etc. This should be very conservative with its assumptions on shared file systems and accessibility. In general, what needs to be stated here are what are the underlying aspects of the underlying resource that are exposed to the outward facing interface. 2) A way of naming a submission point (should probably have a way of modeling queues). 3) A core set of job management operations, submit, status, kill. These need to be defined in such a way at to be tolerate to a variety of failure scenarios, in that the state needs to be well defined in the case of failure. 4) A state model that one can use to describe what is going on with the jobs and a way to access that state. Can be simple (queued, running, done), may need to be extensible. One can view the accounting information as being exposed So, one thing to do would be to agree that these are (or are not) the right four things that need to be defined and if so, start to flesh out these in a way that supports the core use case but doesn't introduce assumptions that would preclude more complex use cases in the future. Carl ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marty Humphrey Sent: Tuesday, March 14, 2006 6:32 AM To: ogsa-wg(a)ggf.org Cc: 'Marvin Theimer' Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Carl, Your comments are very important. We would love to have your active participation in this effort. Your experience is, of course, matched by few! I re-emphasize that this represents (my words, not anyone else's) "baby steps" that are necessary and important for the Grid community. In my opinion, the biggest challenge will be to fight the urge to expand the scope beyond a small size. You cannot ignore the possibility that the GGF has NOT made as much progress as it should have to date. Furthermore, one such plausible explanation is that the scope is too grand. -- Marty ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Carl Kesselman Sent: Tuesday, March 14, 2006 8:47 AM To: Marvin Theimer; Ian Foster; ogsa-wg(a)ggf.org Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Hi, While I have no wish to engage in the "what is a Grid" argument, there are some elements of your base use case that I would be concerned about. Specifically, the assumption that the submission in into a "local cluster" on which there is an existing account may lead one to a solution that may not generalize to the solution to the case of submission across autonomous policy domains. I would also argue that ignoring issues of fault tolerance from the beginning is also problematic. One must at least design operations that are restartable (for example at most once submission semantics). I would finally suggest that while examining existing job schedule systems is a good thing to do, we should also examine existing remote submission systems (dare I say Grid systems). The basic HPC use case is one in which there is a significant amount implementation and usage experience. Thanks, Carl ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marvin Theimer Sent: Monday, March 13, 2006 2:42 PM To: Ian Foster; ogsa-wg(a)ggf.org Cc: Marvin Theimer Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Hi; Ian, you are correct that I view job submission to a cluster as being one of the simplest, and hence most basic, HPC use cases to start with. Or, to be slightly more general, I view job submission to a "black box" that can run jobs - be it a cluster or an SMP or an SGI NUMA machine or what-have-you - as being the simplest and hence most basic HPC use case to start with. The key distinction for me is that the internals of the "box" are for the most part not visible to the client, at least as far as submitting and running compute jobs is concerned. There may well be a separate interface for dealing with things like system management, but I want to explicitly separate those things out in order to allow for use of "boxes" that might be managed by proprietary means or by means obeying standards that a particular job submission client is unfamiliar with. I think the use case that Ravi Subramaniam posted to this mailing list back on 2/17 is a good one to start a discussion around. However, I'd like to present it from a different point-of-view than he did. The manner in which the use case is currently presented emphasizes all the capabilities and services needed to handle the fully general case of submitting a batch job to a computing utility/service. That's a great way of producing a taxonomy against which any given system or design can be compared to see what it has to offer. I would argue that the next step is to ask what's the simplest subset that represents a useful system/design and how should one categorize the various capabilities and services he has identified so as to arrive at meaningful components that can be selectively used to obtain progressively more capable systems. Another useful exercise to do is to examine existing job scheduling systems in order to understand what they provide. Since in the real world we will have to deal with the legacy of existing systems it will be important to understand how they relate to the use cases we explore. In the same vein, it will be important to take into account and understand other existing infrastructures that people use that are related to HPC use cases. I'm thinking of things like security infrastructures, directory services, and so forth. From the point-of-view of managing complexity and reducing total-cost-of-ownership, it will be important to understand the extent to which existing infrastructure and services can be reused rather than reinvented. To kick off a discussion around the topic of a minimalist HPC use case, I present a straw man description of such below and then present a first attempt at categorizing various areas of extension. The categorization of extension areas is not meant to be complete or even all that carefully thought-out as far as componentization boundaries are concerned; it is merely meant to be a first contribution to get the discussion going. A basic HPC use case: Compute cluster embedded within an organization. * This is your basic batch job scheduling scenario. Only a very basic state transition diagram is visible to the client, with the following states for a job: queued, running, finished. Additional states -- and associated state transition request operations and functionality -- are not supported. Examples of additional states and associated functionality include suspension of jobs and migration of jobs. * Only "standard" resources can be described, for example: number of cpus/nodes needed, memory requirements, disk requirements, etc. (think resources that are describable by JSDL). * Once a job has been submitted it can be cancelled, but its resource requests can't be modified. * A distributed file system is accessible from client desktop machines and client file servers, as well as compute nodes of the compute cluster. This implies that no data staging is required, that programs can be (for the most part) executed from existing file system locations, and that no program "provisioning" is required (since you can execute them from wherever they are already installed). Thus in this use case all data transfer and program installation operations are the responsibility of the user. * Users already have accounts within the existing security infrastructure (e.g. Kerberos). They would like to use these and not have to create/manage additional authentication/authorization credentials (at least at the level that is visible to them). * The job scheduling service resides at a well-known network name and it is aware of the compute cluster and its resources by "private" means (e.g. it runs on the head node of the cluster and employs private means to monitor and control the resources of the cluster). This implies that there is no need for any sort of directory services for finding the compute cluster or the resources it represents other than basic DNS. * Compute cluster system management is opaque to users and is the concern of the compute cluster's owners. This implies that system management is not part of the compute cluster's public job scheduling interface. This also implies that there is no need for a logging interface to the service. I assume that application-level logging can be done by means of libraries that write to client files; i.e. that there is no need for any sort of special system support for logging. * A simple polling-based interface is the simplest form of interface to something like a job scheduling service. However, a simple call-back notification interface is a very useful addition that potentially provides substantial performance benefits since it can enable the avoidance of lots of unnecessary network traffic. Only job state changes result in notification messages. * There are no notions of fault tolerance. Jobs that fail must be resubmitted by the client. Neither the cluster head node nor its compute nodes are fault tolerant. I do expect the client software to return an indication of failure-due-system-fault when appropriate. (Note that this may also occur when things like network partitions occur.) * One does need some notion of how to deal with orphaned resources and jobs. The notion of job lifetime and post-expiration garbage collection is a natural approach here. * The scheduling service provides a fixed set of scheduling policies, with only a few basic choices (or maybe even just one), such as FIFO or round-robin. There is no notion, in general, of SLAs (which are a form of scheduling policy). * Enough information must be returned to the client when a job finishes to enable basic accounting functionality. This means things like total wall-clock time the job ran and a summary of resources used. There is not a need for the interface to support any sort of grouping of accounting information. That is, jobs do not need to be associated with projects, groups, or other accounting entities and the job scheduling service is not responsible for tracking accounting information across such entities. As long as basic resource utilization information is returnable for each job, accounting can be done externally to the job scheduling service. I do assume that jobs can be uniquely identified by some means and can be uniquely associated with some principal entity existing in the overall system, such as a user name. * Just as there is no notion of requiring the job scheduling service to track any but the most basic job-level accounting information, there is no notion of the service enforcing quotas on jobs. * Although it is generally useful to separate the notions of resource reservation from resource usage (e.g. to enable interactive and debugging use of resources), it is not a necessity for the most basic of job scheduling services. * There is no notion of tying multiple jobs together, either to support things like dependency graphs or to support things like workflows. Such capabilities must be implemented by clients of the job scheduling service. Interesting extension areas: * Additional scheduling policies o Weighted fair-share, ... o Multiple queues o SLAs o ... * Extended resource descriptions o Additional resource types, such as GPUs o Additional types of compute resources, such as desktop computers o Condor-style class ads * Extended job descriptions (as returned to requesting clients and sys admins) * Additional classes of security credentials * Reservations separated from execution o Enabling interactive and debugging jobs o Support for multiple competing schedulers (incl. desktop cycle stealing and market-based approaches to scheduling compute resources) * Ability to modify jobs during their existence * Fault tolerance o Automatic rescheduling of jobs that failed due to system faults o Highly available resources: This is partly a policy statement by a scheduling service about its characteristics and partly the ability to rebind clients to migrated service endpoints * Extended state transition diagrams and associated functionalities o Job suspension o Job migration o ... * Accounting & quotas * Operating on arrays of jobs * Meta-schedulers, multiple schedulers, and ecologies and hierarchies of multiple schedulers o Meta-schedulers * Hierarchical job scheduling with a meta-scheduler as the only entry point; forwarding jobs to the meta-scheduler from other subsidiary schedulers o Condor-style matchmaking * Directory services o Using existing directory services o Abstract directory service interface(s) * Data transfer topics o Application data staging * Naming * Efficiency * Convenience * Cleanup o Program staging/provisioning * Description * Installation * Cleanup Marvin. ________________________________ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Monday, February 20, 2006 9:20 AM To: Marvin Theimer; ogsa-wg(a)ggf.org Cc: Marvin Theimer; Savas Parastatidis; Tony Hey; Marty Humphrey; gcf(a)grids.ucs.indiana.edu Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Dear All: The most important thing to understand at this point (IMHO) is the scope of this "HPC use case," as this will determine just how minimal we can be. I get the impression that the principal goal may be "job submission to a cluster." Is that correct? How do we start to circumscribe the scope more explicitly? Ian. At 05:45 AM 2/16/2006 -0800, Marvin Theimer wrote: Enclosed is a paper that advocates an additional set of activities that the authors believe that the OGSA working groups should engage in. Broadly speaking, the OGSA and related working groups are already doing a bunch of important things: * There is broad exploration of the big picture, including enumeration of use cases, taxonomy of areas, identification of research issues, etc. * There is work going on in each of the horizontal areas that have been identified, such as EMS, data services, etc. * There is working going around individual specifications, such as BES, JSDL, etc. Given that individual specifications are beginning to come to fruition, the authors believe it is time to also start defining vertical profilesthat precisely describe how groups of individual specifications should be employed to implement specific use cases in an interoperable manner. The authors also believe that the process of defining these profiles offers an opportunity to close the design loopby relating the various on-going protocol and standards efforts back to the use cases in a very concrete manner. This provides an end-to-end setting in which to identify holes and issues that might require additional protocols and/or (incremental) changes to existing protocols. The paper introduces both the general notion of doing focused vertical design effortsand then focuses on a specific vertical design effort, namely a minimal HPC design. The paper derives a specific HPC design in a first principlesmanner since the authors believe that this increases the chances of identifying issues. As a consequence, existing specifications and the activities of existing working groups are not mentioned and this paper is not an attempt to actually define a specifications profile. Also, the absence of references to existing work is not meant to imply that such work is in any way irrelevant or inappropriate. The paper should be viewed as a first abstract attempt to propose a new kind of activity within OGSA. The expectation is that future open discussions and publications will explore the concrete details of such a proposal. This paper was recently sent to a few key individuals in order to get feedback from them before submitting it to the wider GGF community. Unfortunately that process took longer than intended and some members of the community may have already seen a copy of the paper without knowing the context within it was written. This email should hopefully dispel any misconceptions that may have occurred. For those people who will be around on for the F2F meetings on Friday, Marvin Theimer will be giving a talk on the contents of this paper at a time and place to be announced. Marvin Theimer, Savas Parastatidis, Tony Hey, Marty Humphrey, Geoffrey Fox _______________________________________________________________ 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 <http://www.globus.org/>

2 1

FW: [cddlm] Revised CDL for BLAST slides (Re: Proposed agenda for March 15th call)
by Milojicic, Dejan S (HP Labs) 15 Mar '06

15 Mar '06

Hi Hiro and the Teams, We discussed your presentation at the CDDLM meeting. We have questions about the following aspects: 1. The presented comparison is a little bit of apples-to-oranges. We are comparing a job submission with the deployment tool. What exactly do we want to accomplish? For example, should we provide a list of "JSDL document does not include" as an equivalent to slide 6 in the last presentation you have sent? 2. You start from a radically simple case, which does not emphasize any of the CDL features: dependencies, lazy evaluation, naming, etc. You do not even have the need to deploy the BLAST application, it is stored in a well know location on the local system. Should we not expand it for where there is a need for deployment? 3. Is this example good enough for you? What about other more complex scenarios? Do you plan to introduce them. I think for balanced evaluation, you may want to address two scenarios upfront and how they are addressed by both tools. In a summary, how should we take it further? Should we extend the example you had with what CDL does? Should we target the F2F for this purpose? Thanks, Dejan. Also, I include the follow-up message From Jun Tatemura, which further clarifies: I went through the newer version of CDLforBLAST slides. My understanding on this slides is that they expect CDDLM/CDL to deploy (configure) - application binary (installation of blast binary and required environment) - file system (mount file system) - database (setup -- I don't know details on what must be set up...) - environment variables and let JSDL do the rest. If so, what we can do would be: (1) first, we want to confirm that this is the line they want to draw (--> your question 1 comes here. It this what they mean?) (2) if we agree on the line, then we would like to have more information on the requirement (and/or assumed environment) to deploy the above so that we can design CDDLM components for this use case. (--> your questions 2,3 are aligned with this - how much we should extend the deployment requirements from the base case (where everything is already available)) (3) Once we have components, we can write CDL and discuss how CDL and JSDL interact. Thanks, Jun > -----Original Message----- > From: owner-cddlm-wg(a)ggf.org [mailto:owner-cddlm-wg@ggf.org] On Behalf > Of Hiro Kishimoto > Sent: Tuesday, March 14, 2006 9:18 PM > To: OGSA WG; cddlm-wg(a)ggf.org > Subject: [cddlm] Revised CDL for BLAST slides (Re: Proposed agenda for > March 15th call) > > Hi all, > > I've added Chris Smith's comments to CDL for BLAST slides, Let's > review this at this OGSA-WG call tomorrow. > > It is also uploaded to gridforge; > https://forge.gridforum.org/projects/ogsa-wg/document/CDL_for_BLAST > > Thanks, > ---- > Hiro Kishimoto > > Hiro Kishimoto wrote: > > Hi all, > > > > The following is a proposed agenda for OGSA-WG telecon on > March 15th > > Wednesday from 4pm to 6pm (CST). > > > > Dial-in numbers for Wednesday: > > Free: +1-888-452-0308 > > Intl/Toll: +1-484-644-0505 > > PIN: 71815 > > > > Screen share service will be provided. > > URL: http://ogsa.glance.net > > Session key: 0315 > > See more explanation: > > > http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.ht > > ml > > > > 1) Early discussion (20 min) > > Note taker assignment > > Roll call > > Telecon minutes approval (if available) > > Agenda bashing > > > > 2) April F2F meeting update (20 min) > > > > F2F meeting venue is Intel@Santa Clara & Fujitsu@Sunnyvale. > > The updated session schedule is uploaded to GridForge: > > > https://forge.gridforum.org/projects/ogsa-wg/document/200604F2F_sessio > > n > > > > In order to have general EMS discussion before > CDDLM session, > > is it possible to switch these two sessions? > > a) joint CDDLM-WG session (Apr. 5 Wed. 1:30-4:30pm) > > b) EMS architecture session (Apr. 6 Thu. 9am-12:30pm) > > > > 3) joint CDDLM-WG discussion (60 min) > > > > From the minutes of joint F2F meeting in Athens; > > > >> ACTION: Steven Newhouse to write up a first draft of a few more > >> scenarios on the relationship between JSDL and CDL. > >> - To be included in the current EMS scenarios document. > - To be > >> delivered by mid-March > >> - Review on an OGSA call and continue refinement > >> > >> ** Whiteboard list produced during the discussion > >> > >> - Duplication of JSDL in CDL? > >> - Directory/user creation > >> - What is the difference between [job / application / > container] > >> configuration] > >> - Where is line between JSDL and CDL and is it policy specific > >> - Job lifecycle including deployment and start/stop > > > > > > Steven will send out revised version of his > "interaction between > > CDDLM & JSDL" scenarios before the call. > > > > Revised "CDL for BLAST" slides attached. > > > > 4) Wrap up (10 min) > > AOB > > > > <NEXT CALL> > > March 20 (Mon): OGSA-HPC profile (Marvin) March 22 (Wed): Security > > Architecture (Takuya and Frank) March 27 (Mon): EMS scenarios, > > Steven's scenarios review, > > Information Model, Ellen's CIM profile > review March 29 > > (Wed): F2F preparation > > > > Telecon schedule: > > > https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule > > / > > >

1 0

RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Subramaniam, Ravi 15 Mar '06

15 Mar '06

Hi Marvin, Thanks for documenting and explaining what you see as the basic HPC case. I agree with your observations and what you have listed are what most, if not all HPC cluster systems I know of, implement. I think there is something else that may be apparent. If I may suggest that the bulleted list with the exception of the "11th (?)" bullet would nicely fit into the BES situation. If I look at the cluster you describe (i.e. the client perspective with queued, running and finished) it seem to me that that would be a BES container (at least from an interface perspective and where the scheduler that you are submitting the jobs to is the abstract representation of the BES "container"). We had discussed this recursive container concept in the EMS discussion in OGSA V1.0. This seems especially true since you advocate that in this simple HPC case a "user" would not have visibility into the granular elements of what makes a cluster and the operations would essentially be within this "black box". Would it make sense to add most of these notions to the BES discussion and the scheduler aspects would fit in RSS (where they could provide a basic RSS interface)? Putting these together with some minor additional specs may be the basic HPC profile. Am I missing something? Thanks! Ravi ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marvin Theimer Sent: Monday, March 13, 2006 2:42 PM To: Ian Foster; ogsa-wg(a)ggf.org Cc: Marvin Theimer Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Hi; Ian, you are correct that I view job submission to a cluster as being one of the simplest, and hence most basic, HPC use cases to start with. Or, to be slightly more general, I view job submission to a "black box" that can run jobs - be it a cluster or an SMP or an SGI NUMA machine or what-have-you - as being the simplest and hence most basic HPC use case to start with. The key distinction for me is that the internals of the "box" are for the most part not visible to the client, at least as far as submitting and running compute jobs is concerned. There may well be a separate interface for dealing with things like system management, but I want to explicitly separate those things out in order to allow for use of "boxes" that might be managed by proprietary means or by means obeying standards that a particular job submission client is unfamiliar with. I think the use case that Ravi Subramaniam posted to this mailing list back on 2/17 is a good one to start a discussion around. However, I'd like to present it from a different point-of-view than he did. The manner in which the use case is currently presented emphasizes all the capabilities and services needed to handle the fully general case of submitting a batch job to a computing utility/service. That's a great way of producing a taxonomy against which any given system or design can be compared to see what it has to offer. I would argue that the next step is to ask what's the simplest subset that represents a useful system/design and how should one categorize the various capabilities and services he has identified so as to arrive at meaningful components that can be selectively used to obtain progressively more capable systems. Another useful exercise to do is to examine existing job scheduling systems in order to understand what they provide. Since in the real world we will have to deal with the legacy of existing systems it will be important to understand how they relate to the use cases we explore. In the same vein, it will be important to take into account and understand other existing infrastructures that people use that are related to HPC use cases. I'm thinking of things like security infrastructures, directory services, and so forth. From the point-of-view of managing complexity and reducing total-cost-of-ownership, it will be important to understand the extent to which existing infrastructure and services can be reused rather than reinvented. To kick off a discussion around the topic of a minimalist HPC use case, I present a straw man description of such below and then present a first attempt at categorizing various areas of extension. The categorization of extension areas is not meant to be complete or even all that carefully thought-out as far as componentization boundaries are concerned; it is merely meant to be a first contribution to get the discussion going. A basic HPC use case: Compute cluster embedded within an organization. * This is your basic batch job scheduling scenario. Only a very basic state transition diagram is visible to the client, with the following states for a job: queued, running, finished. Additional states -- and associated state transition request operations and functionality -- are not supported. Examples of additional states and associated functionality include suspension of jobs and migration of jobs. * Only "standard" resources can be described, for example: number of cpus/nodes needed, memory requirements, disk requirements, etc. (think resources that are describable by JSDL). * Once a job has been submitted it can be cancelled, but its resource requests can't be modified. * A distributed file system is accessible from client desktop machines and client file servers, as well as compute nodes of the compute cluster. This implies that no data staging is required, that programs can be (for the most part) executed from existing file system locations, and that no program "provisioning" is required (since you can execute them from wherever they are already installed). Thus in this use case all data transfer and program installation operations are the responsibility of the user. * Users already have accounts within the existing security infrastructure (e.g. Kerberos). They would like to use these and not have to create/manage additional authentication/authorization credentials (at least at the level that is visible to them). * The job scheduling service resides at a well-known network name and it is aware of the compute cluster and its resources by "private" means (e.g. it runs on the head node of the cluster and employs private means to monitor and control the resources of the cluster). This implies that there is no need for any sort of directory services for finding the compute cluster or the resources it represents other than basic DNS. * Compute cluster system management is opaque to users and is the concern of the compute cluster's owners. This implies that system management is not part of the compute cluster's public job scheduling interface. This also implies that there is no need for a logging interface to the service. I assume that application-level logging can be done by means of libraries that write to client files; i.e. that there is no need for any sort of special system support for logging. * A simple polling-based interface is the simplest form of interface to something like a job scheduling service. However, a simple call-back notification interface is a very useful addition that potentially provides substantial performance benefits since it can enable the avoidance of lots of unnecessary network traffic. Only job state changes result in notification messages. * There are no notions of fault tolerance. Jobs that fail must be resubmitted by the client. Neither the cluster head node nor its compute nodes are fault tolerant. I do expect the client software to return an indication of failure-due-system-fault when appropriate. (Note that this may also occur when things like network partitions occur.) * One does need some notion of how to deal with orphaned resources and jobs. The notion of job lifetime and post-expiration garbage collection is a natural approach here. * The scheduling service provides a fixed set of scheduling policies, with only a few basic choices (or maybe even just one), such as FIFO or round-robin. There is no notion, in general, of SLAs (which are a form of scheduling policy). * Enough information must be returned to the client when a job finishes to enable basic accounting functionality. This means things like total wall-clock time the job ran and a summary of resources used. There is not a need for the interface to support any sort of grouping of accounting information. That is, jobs do not need to be associated with projects, groups, or other accounting entities and the job scheduling service is not responsible for tracking accounting information across such entities. As long as basic resource utilization information is returnable for each job, accounting can be done externally to the job scheduling service. I do assume that jobs can be uniquely identified by some means and can be uniquely associated with some principal entity existing in the overall system, such as a user name. * Just as there is no notion of requiring the job scheduling service to track any but the most basic job-level accounting information, there is no notion of the service enforcing quotas on jobs. * Although it is generally useful to separate the notions of resource reservation from resource usage (e.g. to enable interactive and debugging use of resources), it is not a necessity for the most basic of job scheduling services. * There is no notion of tying multiple jobs together, either to support things like dependency graphs or to support things like workflows. Such capabilities must be implemented by clients of the job scheduling service. Interesting extension areas: * Additional scheduling policies o Weighted fair-share, ... o Multiple queues o SLAs o ... * Extended resource descriptions o Additional resource types, such as GPUs o Additional types of compute resources, such as desktop computers o Condor-style class ads * Extended job descriptions (as returned to requesting clients and sys admins) * Additional classes of security credentials * Reservations separated from execution o Enabling interactive and debugging jobs o Support for multiple competing schedulers (incl. desktop cycle stealing and market-based approaches to scheduling compute resources) * Ability to modify jobs during their existence * Fault tolerance o Automatic rescheduling of jobs that failed due to system faults o Highly available resources: This is partly a policy statement by a scheduling service about its characteristics and partly the ability to rebind clients to migrated service endpoints * Extended state transition diagrams and associated functionalities o Job suspension o Job migration o ... * Accounting & quotas * Operating on arrays of jobs * Meta-schedulers, multiple schedulers, and ecologies and hierarchies of multiple schedulers o Meta-schedulers * Hierarchical job scheduling with a meta-scheduler as the only entry point; forwarding jobs to the meta-scheduler from other subsidiary schedulers o Condor-style matchmaking * Directory services o Using existing directory services o Abstract directory service interface(s) * Data transfer topics o Application data staging * Naming * Efficiency * Convenience * Cleanup o Program staging/provisioning * Description * Installation * Cleanup Marvin. ________________________________ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Monday, February 20, 2006 9:20 AM To: Marvin Theimer; ogsa-wg(a)ggf.org Cc: Marvin Theimer; Savas Parastatidis; Tony Hey; Marty Humphrey; gcf(a)grids.ucs.indiana.edu Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Dear All: The most important thing to understand at this point (IMHO) is the scope of this "HPC use case," as this will determine just how minimal we can be. I get the impression that the principal goal may be "job submission to a cluster." Is that correct? How do we start to circumscribe the scope more explicitly? Ian. At 05:45 AM 2/16/2006 -0800, Marvin Theimer wrote: Enclosed is a paper that advocates an additional set of activities that the authors believe that the OGSA working groups should engage in. Broadly speaking, the OGSA and related working groups are already doing a bunch of important things: * There is broad exploration of the big picture, including enumeration of use cases, taxonomy of areas, identification of research issues, etc. * There is work going on in each of the horizontal areas that have been identified, such as EMS, data services, etc. * There is working going around individual specifications, such as BES, JSDL, etc. Given that individual specifications are beginning to come to fruition, the authors believe it is time to also start defining vertical profilesthat precisely describe how groups of individual specifications should be employed to implement specific use cases in an interoperable manner. The authors also believe that the process of defining these profiles offers an opportunity to close the design loopby relating the various on-going protocol and standards efforts back to the use cases in a very concrete manner. This provides an end-to-end setting in which to identify holes and issues that might require additional protocols and/or (incremental) changes to existing protocols. The paper introduces both the general notion of doing focused vertical design effortsand then focuses on a specific vertical design effort, namely a minimal HPC design. The paper derives a specific HPC design in a first principlesmanner since the authors believe that this increases the chances of identifying issues. As a consequence, existing specifications and the activities of existing working groups are not mentioned and this paper is not an attempt to actually define a specifications profile. Also, the absence of references to existing work is not meant to imply that such work is in any way irrelevant or inappropriate. The paper should be viewed as a first abstract attempt to propose a new kind of activity within OGSA. The expectation is that future open discussions and publications will explore the concrete details of such a proposal. This paper was recently sent to a few key individuals in order to get feedback from them before submitting it to the wider GGF community. Unfortunately that process took longer than intended and some members of the community may have already seen a copy of the paper without knowing the context within it was written. This email should hopefully dispel any misconceptions that may have occurred. For those people who will be around on for the F2F meetings on Friday, Marvin Theimer will be giving a talk on the contents of this paper at a time and place to be announced. Marvin Theimer, Savas Parastatidis, Tony Hey, Marty Humphrey, Geoffrey Fox _______________________________________________________________ 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 <http://www.globus.org/>

2 1

Action item from mondays call
by Andrew Grimshaw 15 Mar '06

15 Mar '06

All, On the call Monday night I was asked to provide a few paragraphs on provisioning versus instance instantiation and "currying". To me this is pretty straight-forward. I provision an application on my computer by installing it. CDL is the tool for that. Every time I want to run the program, I create a separate application instance - JSDL/BES is the right tool for that. With respect to whether a particular input is bound to the application (as came up in the call). More formally: Assume that a program is a function L(a,b,c,d, .) that maps the inputs to some set of outputs. (We'll assume that the programs are deterministic.) If we bind the formal parameter "a" with a particular value (say a particular input file), then we have effectively created a new function L'(b,c,d, ..). L and L' are two different functions. In lambda calculus this is called "currying" - I've also seen it called "reification" in other contexts. In terms of programs like BLAST. BLAST basically takes an input sequence database and an input sequence and generates a set of scores - usually the top k scores. . (There are many other parameters, but lets focus on the two major ones.) The scores are generated by comparing the input sequence against each of the target sequences in the database. If we "bind" BLAST to a particular target database - then we have effectively created a new BLAST, BLASTBound_to_the_particular_database. It is not the same function any more. In terms of the discussion we've been having on the differences of the roles of CDL and JSDL/BES I think if it this way. If I want to be able to run BLAST on a machine - I may use (via perhaps the program manager) CDL to "provision" BLAST in the BES container. To run BLAST with a particular set of input files, then I use JSDL/BES. If I am going to be running a large number of "BLAST jobs" against a particular DB, I may want to "provision" BLASTBound_to_the_particular_database , using CDL, and then run a set of comparisons against particular sequences using JSDL/BES. Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

1 0

Webcast thoughts
by Andrew Grimshaw 15 Mar '06

15 Mar '06

All, I'd like to start an email discussion in advance of the F2F on the webcast content. While we do have an initial set of slides - I think we need to make sure that we design the talk for our expected audience - rather than based on the material we already have in the deck. When Dave I went to MS our slide deck was not technical enough - we had the wrong talk with us, and so had to improvise. So, one of the things I'd like to know is: Who is our expected audience? Is it technical people, if so, are they web services aware?, are they applications developers? Or are they mostly managers and planners. Or do we have to try and make everyone happy. Any insight? A Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

1 0

Proposed agenda for March 15th call
by Hiro Kishimoto 15 Mar '06

15 Mar '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 15th Wednesday from 4pm to 6pm (CST). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0315 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (if available) Agenda bashing 2) April F2F meeting update (20 min) F2F meeting venue is Intel@Santa Clara & Fujitsu@Sunnyvale. The updated session schedule is uploaded to GridForge: https://forge.gridforum.org/projects/ogsa-wg/document/200604F2F_session In order to have general EMS discussion before CDDLM session, is it possible to switch these two sessions? a) joint CDDLM-WG session (Apr. 5 Wed. 1:30-4:30pm) b) EMS architecture session (Apr. 6 Thu. 9am-12:30pm) 3) joint CDDLM-WG discussion (60 min) From the minutes of joint F2F meeting in Athens; > ACTION: Steven Newhouse to write up a first draft of a few more > scenarios on the relationship between JSDL and CDL. > - To be included in the current EMS scenarios document. > - To be delivered by mid-March > - Review on an OGSA call and continue refinement > > ** Whiteboard list produced during the discussion > > - Duplication of JSDL in CDL? > - Directory/user creation > - What is the difference between > [job / application / container] configuration] > - Where is line between JSDL and CDL and is it policy specific > - Job lifecycle including deployment and start/stop Steven will send out revised version of his "interaction between CDDLM & JSDL" scenarios before the call. Revised "CDL for BLAST" slides attached. 4) Wrap up (10 min) AOB <NEXT CALL> March 20 (Mon): OGSA-HPC profile (Marvin) March 22 (Wed): Security Architecture (Takuya and Frank) March 27 (Mon): EMS scenarios, Steven's scenarios review, Information Model, Ellen's CIM profile review March 29 (Wed): F2F preparation Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 1

Minutes from the March 13 telecon
by Treadwell, Jem 14 Mar '06

14 Mar '06

Hi, the minutes from Monday's OGSA telecon are attached and in GridForge at http://tinyurl.com/fgkmf. - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com>

1 0

RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Carl Kesselman 14 Mar '06

14 Mar '06

Hi, While I have no wish to engage in the "what is a Grid" argument, there are some elements of your base use case that I would be concerned about. Specifically, the assumption that the submission in into a "local cluster" on which there is an existing account may lead one to a solution that may not generalize to the solution to the case of submission across autonomous policy domains. I would also argue that ignoring issues of fault tolerance from the beginning is also problematic. One must at least design operations that are restartable (for example at most once submission semantics). I would finally suggest that while examining existing job schedule systems is a good thing to do, we should also examine existing remote submission systems (dare I say Grid systems). The basic HPC use case is one in which there is a significant amount implementation and usage experience. Thanks, Carl ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marvin Theimer Sent: Monday, March 13, 2006 2:42 PM To: Ian Foster; ogsa-wg(a)ggf.org Cc: Marvin Theimer Subject: RE: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Hi; Ian, you are correct that I view job submission to a cluster as being one of the simplest, and hence most basic, HPC use cases to start with. Or, to be slightly more general, I view job submission to a "black box" that can run jobs - be it a cluster or an SMP or an SGI NUMA machine or what-have-you - as being the simplest and hence most basic HPC use case to start with. The key distinction for me is that the internals of the "box" are for the most part not visible to the client, at least as far as submitting and running compute jobs is concerned. There may well be a separate interface for dealing with things like system management, but I want to explicitly separate those things out in order to allow for use of "boxes" that might be managed by proprietary means or by means obeying standards that a particular job submission client is unfamiliar with. I think the use case that Ravi Subramaniam posted to this mailing list back on 2/17 is a good one to start a discussion around. However, I'd like to present it from a different point-of-view than he did. The manner in which the use case is currently presented emphasizes all the capabilities and services needed to handle the fully general case of submitting a batch job to a computing utility/service. That's a great way of producing a taxonomy against which any given system or design can be compared to see what it has to offer. I would argue that the next step is to ask what's the simplest subset that represents a useful system/design and how should one categorize the various capabilities and services he has identified so as to arrive at meaningful components that can be selectively used to obtain progressively more capable systems. Another useful exercise to do is to examine existing job scheduling systems in order to understand what they provide. Since in the real world we will have to deal with the legacy of existing systems it will be important to understand how they relate to the use cases we explore. In the same vein, it will be important to take into account and understand other existing infrastructures that people use that are related to HPC use cases. I'm thinking of things like security infrastructures, directory services, and so forth. From the point-of-view of managing complexity and reducing total-cost-of-ownership, it will be important to understand the extent to which existing infrastructure and services can be reused rather than reinvented. To kick off a discussion around the topic of a minimalist HPC use case, I present a straw man description of such below and then present a first attempt at categorizing various areas of extension. The categorization of extension areas is not meant to be complete or even all that carefully thought-out as far as componentization boundaries are concerned; it is merely meant to be a first contribution to get the discussion going. A basic HPC use case: Compute cluster embedded within an organization. * This is your basic batch job scheduling scenario. Only a very basic state transition diagram is visible to the client, with the following states for a job: queued, running, finished. Additional states -- and associated state transition request operations and functionality -- are not supported. Examples of additional states and associated functionality include suspension of jobs and migration of jobs. * Only "standard" resources can be described, for example: number of cpus/nodes needed, memory requirements, disk requirements, etc. (think resources that are describable by JSDL). * Once a job has been submitted it can be cancelled, but its resource requests can't be modified. * A distributed file system is accessible from client desktop machines and client file servers, as well as compute nodes of the compute cluster. This implies that no data staging is required, that programs can be (for the most part) executed from existing file system locations, and that no program "provisioning" is required (since you can execute them from wherever they are already installed). Thus in this use case all data transfer and program installation operations are the responsibility of the user. * Users already have accounts within the existing security infrastructure (e.g. Kerberos). They would like to use these and not have to create/manage additional authentication/authorization credentials (at least at the level that is visible to them). * The job scheduling service resides at a well-known network name and it is aware of the compute cluster and its resources by "private" means (e.g. it runs on the head node of the cluster and employs private means to monitor and control the resources of the cluster). This implies that there is no need for any sort of directory services for finding the compute cluster or the resources it represents other than basic DNS. * Compute cluster system management is opaque to users and is the concern of the compute cluster's owners. This implies that system management is not part of the compute cluster's public job scheduling interface. This also implies that there is no need for a logging interface to the service. I assume that application-level logging can be done by means of libraries that write to client files; i.e. that there is no need for any sort of special system support for logging. * A simple polling-based interface is the simplest form of interface to something like a job scheduling service. However, a simple call-back notification interface is a very useful addition that potentially provides substantial performance benefits since it can enable the avoidance of lots of unnecessary network traffic. Only job state changes result in notification messages. * There are no notions of fault tolerance. Jobs that fail must be resubmitted by the client. Neither the cluster head node nor its compute nodes are fault tolerant. I do expect the client software to return an indication of failure-due-system-fault when appropriate. (Note that this may also occur when things like network partitions occur.) * One does need some notion of how to deal with orphaned resources and jobs. The notion of job lifetime and post-expiration garbage collection is a natural approach here. * The scheduling service provides a fixed set of scheduling policies, with only a few basic choices (or maybe even just one), such as FIFO or round-robin. There is no notion, in general, of SLAs (which are a form of scheduling policy). * Enough information must be returned to the client when a job finishes to enable basic accounting functionality. This means things like total wall-clock time the job ran and a summary of resources used. There is not a need for the interface to support any sort of grouping of accounting information. That is, jobs do not need to be associated with projects, groups, or other accounting entities and the job scheduling service is not responsible for tracking accounting information across such entities. As long as basic resource utilization information is returnable for each job, accounting can be done externally to the job scheduling service. I do assume that jobs can be uniquely identified by some means and can be uniquely associated with some principal entity existing in the overall system, such as a user name. * Just as there is no notion of requiring the job scheduling service to track any but the most basic job-level accounting information, there is no notion of the service enforcing quotas on jobs. * Although it is generally useful to separate the notions of resource reservation from resource usage (e.g. to enable interactive and debugging use of resources), it is not a necessity for the most basic of job scheduling services. * There is no notion of tying multiple jobs together, either to support things like dependency graphs or to support things like workflows. Such capabilities must be implemented by clients of the job scheduling service. Interesting extension areas: * Additional scheduling policies o Weighted fair-share, ... o Multiple queues o SLAs o ... * Extended resource descriptions o Additional resource types, such as GPUs o Additional types of compute resources, such as desktop computers o Condor-style class ads * Extended job descriptions (as returned to requesting clients and sys admins) * Additional classes of security credentials * Reservations separated from execution o Enabling interactive and debugging jobs o Support for multiple competing schedulers (incl. desktop cycle stealing and market-based approaches to scheduling compute resources) * Ability to modify jobs during their existence * Fault tolerance o Automatic rescheduling of jobs that failed due to system faults o Highly available resources: This is partly a policy statement by a scheduling service about its characteristics and partly the ability to rebind clients to migrated service endpoints * Extended state transition diagrams and associated functionalities o Job suspension o Job migration o ... * Accounting & quotas * Operating on arrays of jobs * Meta-schedulers, multiple schedulers, and ecologies and hierarchies of multiple schedulers o Meta-schedulers * Hierarchical job scheduling with a meta-scheduler as the only entry point; forwarding jobs to the meta-scheduler from other subsidiary schedulers o Condor-style matchmaking * Directory services o Using existing directory services o Abstract directory service interface(s) * Data transfer topics o Application data staging * Naming * Efficiency * Convenience * Cleanup o Program staging/provisioning * Description * Installation * Cleanup Marvin. ________________________________ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Monday, February 20, 2006 9:20 AM To: Marvin Theimer; ogsa-wg(a)ggf.org Cc: Marvin Theimer; Savas Parastatidis; Tony Hey; Marty Humphrey; gcf(a)grids.ucs.indiana.edu Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts" Dear All: The most important thing to understand at this point (IMHO) is the scope of this "HPC use case," as this will determine just how minimal we can be. I get the impression that the principal goal may be "job submission to a cluster." Is that correct? How do we start to circumscribe the scope more explicitly? Ian. At 05:45 AM 2/16/2006 -0800, Marvin Theimer wrote: Enclosed is a paper that advocates an additional set of activities that the authors believe that the OGSA working groups should engage in. Broadly speaking, the OGSA and related working groups are already doing a bunch of important things: * There is broad exploration of the big picture, including enumeration of use cases, taxonomy of areas, identification of research issues, etc. * There is work going on in each of the horizontal areas that have been identified, such as EMS, data services, etc. * There is working going around individual specifications, such as BES, JSDL, etc. Given that individual specifications are beginning to come to fruition, the authors believe it is time to also start defining vertical profilesthat precisely describe how groups of individual specifications should be employed to implement specific use cases in an interoperable manner. The authors also believe that the process of defining these profiles offers an opportunity to close the design loopby relating the various on-going protocol and standards efforts back to the use cases in a very concrete manner. This provides an end-to-end setting in which to identify holes and issues that might require additional protocols and/or (incremental) changes to existing protocols. The paper introduces both the general notion of doing focused vertical design effortsand then focuses on a specific vertical design effort, namely a minimal HPC design. The paper derives a specific HPC design in a first principlesmanner since the authors believe that this increases the chances of identifying issues. As a consequence, existing specifications and the activities of existing working groups are not mentioned and this paper is not an attempt to actually define a specifications profile. Also, the absence of references to existing work is not meant to imply that such work is in any way irrelevant or inappropriate. The paper should be viewed as a first abstract attempt to propose a new kind of activity within OGSA. The expectation is that future open discussions and publications will explore the concrete details of such a proposal. This paper was recently sent to a few key individuals in order to get feedback from them before submitting it to the wider GGF community. Unfortunately that process took longer than intended and some members of the community may have already seen a copy of the paper without knowing the context within it was written. This email should hopefully dispel any misconceptions that may have occurred. For those people who will be around on for the F2F meetings on Friday, Marvin Theimer will be giving a talk on the contents of this paper at a time and place to be announced. Marvin Theimer, Savas Parastatidis, Tony Hey, Marty Humphrey, Geoffrey Fox _______________________________________________________________ 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 <http://www.globus.org/>

2 1

Re: [ogsa-wg] Paper proposing "evolutionary vertical design efforts"
by Ian Foster 13 Mar '06

13 Mar '06

Dear All: The most important thing to understand at this point (IMHO) is the scope of this "HPC use case," as this will determine just how minimal we can be. I get the impression that the principal goal may be "job submission to a cluster." Is that correct? How do we start to circumscribe the scope more explicitly? Ian. At 05:45 AM 2/16/2006 -0800, Marvin Theimer wrote: >Enclosed is a paper that advocates an additional set of activities that >the authors believe that the OGSA working groups should engage in. > > > >Broadly speaking, the OGSA and related working groups are already doing a >bunch of important things: > >· There is broad exploration of the big picture, including >enumeration of use cases, taxonomy of areas, identification of research >issues, etc. > >· There is work going on in each of the horizontal areas that have >been identified, such as EMS, data services, etc. > >· There is working going around individual specifications, such as >BES, JSDL, etc. > > > >Given that individual specifications are beginning to come to fruition, >the authors believe it is time to also start defining vertical >profilesthat precisely describe how groups of individual specifications >should be employed to implement specific use cases in an interoperable >manner. The authors also believe that the process of defining these >profiles offers an opportunity to close the design loopby relating the >various on-going protocol and standards efforts back to the use cases in a >very concrete manner. This provides an end-to-end setting in which to >identify holes and issues that might require additional protocols and/or >(incremental) changes to existing protocols. The paper introduces both >the general notion of doing focused vertical design effortsand then >focuses on a specific vertical design effort, namely a minimal HPC design. > > > >The paper derives a specific HPC design in a first principlesmanner since >the authors believe that this increases the chances of identifying >issues. As a consequence, existing specifications and the activities of >existing working groups are not mentioned and this paper is not an attempt >to actually define a specifications profile. Also, the absence of >references to existing work is not meant to imply that such work is in any >way irrelevant or inappropriate. The paper should be viewed as a first >abstract attempt to propose a new kind of activity within OGSA. The >expectation is that future open discussions and publications will explore >the concrete details of such a proposal. > > > >This paper was recently sent to a few key individuals in order to get >feedback from them before submitting it to the wider GGF >community. Unfortunately that process took longer than intended and some >members of the community may have already seen a copy of the paper without >knowing the context within it was written. This email should hopefully >dispel any misconceptions that may have occurred. > > > >For those people who will be around on for the F2F meetings on Friday, >Marvin Theimer will be giving a talk on the contents of this paper at a >time and place to be announced. > > > >Marvin Theimer, Savas Parastatidis, Tony Hey, Marty Humphrey, Geoffrey Fox > > _______________________________________________________________ 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

2 1

Proposed agenda for March 13th call
by Hiro Kishimoto 13 Mar '06

13 Mar '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 13th. Monday from 4pm to 6pm (CST). The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0313 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (March 8th) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060308/en/1 OGSA WSRF BP 1.0 status update (Tom) Agenda bashing 2) EMS scenarios review (60 min) Steven sent out his deployment and provisioning scenarios to the list. Thanks Steven!! http://www-unix.gridforum.org/mail_archive/ogsa-wg/2006/03/msg00024.html > ACTION: Steven Newhouse to write up a first draft of a few more > scenarios on the relationship between JSDL and CDL. > - To be included in the current EMS scenarios document. > - To be delivered by mid-March > - Review on an OGSA call and continue refinement Previous F2F meeting minutes; https://forge.gridforum.org/projects/ogsa-wg/document/ggf16-f2f-minutes-200… https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-f2f-minutes-2006… https://forge.gridforum.org/projects/ogsa-wg/document/cddlm-acs-joint-sessi… EMS module diagram reference by Stuart (under discussion) https://forge.gridforum.org/projects/ogsa-wg/document/GGF15-F2F-OGSA-CDDLM-… BLAST JSDL document example by Chris Smith https://forge.gridforum.org/projects/ogsa-wg/document/jsdl_blast_instance/e… EMS architecture scenario document https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-ems-sc… 3) April F2F meeting venue and agenda (30 min) >From March 8th minutes; > Discussed possible venues in the Bay area. There was a clear > preference for doing the meeting in the Sunnyvale area. It is > expected that the site can be confirmed next week. > Actions: > - Jay will look into IBM facilities in Almaden and Santa Theresa. > - Hiro/Andreas to confirm whether the availability or not of the > Fujitsu facility > - Hiro to ask Ravi whether the Intel facility is available Proposed agenda review https://forge.gridforum.org/projects/ogsa-wg/document/200604F2F_session Survey result as of March 7th (20 answers). https://forge.gridforum.org/projects/ogsa-wg/document/200604_Survey 4) Wrap up (10 min) AOB <NEXT CALL> March 15 (Wed): CDDLM-WG joint call (Dejan and Steven) March 20 (Mon): OGSA-HPC profile (Marvin) March 22 (Wed): Security Architecture (Takuya and Frank) March 27 (Mon): EMS scenarios, Steven's scenarios review, Information Model, Ellen's CIM profile review Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 1

OGSA-EMS Telecon
by Steven Newhouse 13 Mar '06

13 Mar '06

All, Following on from the discussions at the F2F in Athens here are some deployment and provisioning scenarios for discussion on Monday's telecon. Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Director, Open Middleware Infrastructure Institute-UK (OMII-UK) c/o Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

2 2

FINAL CALL: OGSA 1.5 (Architecture and Glossary)
by Andreas Savva 11 Mar '06

11 Mar '06

Final drafts of the OGSA 1.5 documents ([Arch] and [Glossary]) are available on Gridforge. We'd like to submit both documents to the GGF Editor *after the March 8 (Wednesday this week) teleconference*. It's a short deadline but both drafts have been in a fairly stable condition for some time now. Also note that OGSA 1.5 is intended as a minor revision to OGSA 1.0 (GFD-I.30). Please comment on the list or at one of the calls this week. After submission to the GGF Editor these documents will go through a 30-day public comment period, so you will have further opportunities to comment. [Arch] https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-spec-1… (For a change tracked version, see draft 6: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-spec-1…) [Glossary] https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-glossa… -- Andreas Savva Fujitsu Laboratories Ltd

1 1

Teleconference minutes - 8 March 2006
by Andreas Savva 09 Mar '06

09 Mar '06

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060308/en/1 OGSA Teleconference - 8 March 2006 ================================== * Participants Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Ellen Stokes (IBM) Jem Treadwell (HP) Jay Unger (IBM) Minutes: Andreas Savva * Summary of Actions Actions: - Jay will look into IBM facilities in Almaden and Santa Theresa. - Hiro/Andreas to confirm whether the availability or not of the Fujitsu facility - Hiro to ask Ravi whether the Intel facility is available * March 6 minutes approved with no changes * April F2F update Discussed possible venues in the Bay area. There was a clear preference for doing the meeting in the Sunnyvale area. It is expected that the site can be confirmed next week. Group chairs should send agenda requests to Hiro. Marvin can probably attend for one day and Andrew would like to arrange that to be Tuesday or Wednesday so that Naming can also be discussed. Actions: - Jay will look into IBM facilities in Almaden and Santa Theresa. - Hiro/Andreas to confirm whether the availability or not of the Fujitsu facility - Hiro to ask Ravi whether the Intel facility is available * "Guidelines for Information Modeling for OGSA Resources" document review Agreed that in the future reviews documents should have line numbers turned on. (Especially early draft documents.) Section by section review, mainly concentrating on Hiro's comments sent to the list. ** Section 1 - 1.2) Title and contents do not match well. The content is along the lines of use cases. - It is an early draft and will be revised. - Need more description on how to do the rendering/data model. Three options were discussed: 1. Rendering as part of the interface specs 2. RM team draws up guidelines 3. DMTF does rendering It was agreed that 1 & 3 are viable options but 2 is not. Some concerns were also raised on the timeliness of option 3. For example it looks like the WS-CIM will take some time to complete. So option 1 might be better for GGF use. - The text under Figure 1 seems to be slightly out of sync with the example in Figure 2. The example should be showing an XML Schema rather than the representation of an instance. ** Section 2 Agreed with Hiro's proposal to re-organize the text to start from modeling and then move to CIM Profiling. In other words identify what is in the domain specific model, identify CIM portions and generate changes/extensions to CIM. In Section 2.1 OGSA resource is used in a different way from the Glossary definition. Fred will review the definitions and also use Jay's description of 'interesting level of resource' from the point of view of the different capabilities. ** Section 3 Section 3.2 describes 2 ways of doing the modeling work. Involving the RM team in each effort does not scale. So there is a clear need to get involvement from more DMTF experts. Ideally the option of involving the RM team should not even appear in the document but it is probably necessary during the spin up phase. Agreed to re-order the text to put the second approach first. State that it is 'preferred'. ** Section 4 Discussed the standardization process. - Should the documents be information or recommendation track? - Recommendation track may be better. Experimental may also be an option. - There is also a question of the document structure and whether the proposal to the DMTF should be a separate document that is referenced by the profile, or part of the profile. - One idea was to package everything together in one profile document, identify the changes to CIM and then summarize the proposed changes to CIM as an appendix. Doing so would provide the necessary context for the work when taking it to DMTF. - In the case of the JSIM change request the document produced within GGF was submitted with a cover document. - What is the interaction between the GGF and DMTF process? For example, what happens when a DMTF TC changes things in the original GGF document for incorporation into CIM. - Early participation or communication with DMTF WG/TC is important so they know a change request is going to be submitted and noone is surprised. - However even in the case of the JSIM proposal where the CGS WG already had a lot of participation from CIM experts there were changed made in DMTF. - It would make it harder to get buy-in from GGF WGs if their work is subject to modification by a process they have no control over. There should be one more section to cover OGSA interface documents. ** Other comments Should this document reference DSP1001 (profile specification usage guide)? - Probably need a simpler profile template that leads to simpler (shorter) profiles. - Ellen is doing the current work in the spirit of the template but tailored to the needs of GGF. - Security section: Change text to discuss 'secure management' and 'management of security' instead - There should be some description of the tools to be used. E.g., RSM, the Cisco tool for CIM profiling if appropriate, etc. * Webcast update - Jem reported that HP has no branding conditions on the slides etc. - April 26 1:30-3:30 EST is the candidate date. In practice presenters should be available from about 1pm. - Andrew Grimshaw agreed to be a presenter. - Dave Snelling may have a conflict that day. - The webcast preparation will be discussed at the F2F. - The latest slide deck is probably the one used for the IPSphere presentation and should be on gridforge. It needs to be updated--- at the very least to remove/reformat any animations. * OGSA 1.5 - no comments * Next call EMS Scenarios

1 0

Modeling guidelines document -- please review for teleconference on Wednesday
by Fred Maciel 08 Mar '06

08 Mar '06

Hi, I updated the modeling guidelines document. Changes from the previous (pre-GGF16) version are indicated. The latest version can always be found at: http://forge.gridforum.org/projects/ogsa-wg/document/Modeling_Guidelines /en/ We will review this document on the teleconference next wednesday, so please give a look. I'm looking forward to your feedback. Regards, Fred Maciel Hitachi America R&D

2 1

Regrets today
by Maguire_Tom＠emc.com 08 Mar '06

08 Mar '06

Another late night telecon overlap. Btw, I do have a conflict with the April f2f dates. As it stands now I can only attend the first day. Sorry. The following week is not good either. Last two weeks are ok Thanks, Tom Senior Technologist, CTO Office EMC²|SMARTS 44 South Broadway 7th Floor White Plains, NY 10601 Office: +1-914-580-3477 (8280 3477) Mobile: +1-845-729-4806 Email: maguire_tom(a)emc.com If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. Antoine de Saint-Exupery

1 0

Last call for Application Contents Service Specification 1.0
by Keisuke Fukui 08 Mar '06

08 Mar '06

Folks in ogsa-wg, cddlm-wg and acs-wg, We, acs-wg, has come to completion of the ACS Specification 1.0 after discussions and reviews. This is the last call for comments before submission to the GGF Editor for publication. If you have comments, please get them to me by 9 am Japan time on Monday November 7. If there are no significant comments I plan to submit the document on Monday afternoon. Below is the link for the document: https://forge.gridforum.org/projects/acs-wg/document/draft-ggf-acs-spec-1.0… Regards, Keisuke Fukui ACS-WG co-chair

1 1

Proposed agenda for March 8th call
by Hiro Kishimoto 07 Mar '06

07 Mar '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 8th Wednesday from 4pm to 6pm (CST). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0308 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (March 7) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060306/en/1 Agenda bashing 2) April F2F meeting venue (20 min) > Re-selected April 4-7 at west coast (Bay Area) as the first choice. > Possible hosts: > - Hitachi America (Fred to check network connectivity) > - IBM (at a choice of location in the Bay area) > > Action: Candidate hosts should check availability and facilities for > F2F and report back on Wednesday's call F2F session proposal; https://forge.gridforum.org/projects/ogsa-wg/document/200604F2F_session Survey result as of March 7th (20 answers). https://forge.gridforum.org/projects/ogsa-wg/document/200604_Survey 3) Information Modeling Guideline review (60 min) > Fred updated the modeling guidelines document. Changes from the > previous (pre-GGF16) version are indicated. The latest version can > always be found at: > > http://forge.gridforum.org/projects/ogsa-wg/document/Modeling_Guidelines > /en/ 4) OGSA webcast discussion (20 min) > Jem reported that HP can provide the facilities to do an OGSA > webcast, including recording and archiving for later use. Features > also include polls during the webcast, online chat, keeping track of > number of people registering, attendind, how long they attended, > etc. > > Considering the above, a date late in April is better to allow more > time to prepare. The webcast preparation should also be added to the > F2F agenda. > > Action: Jem will check whether there are any HP branding conditions > (or formatting, logos, etc) to the webcast. 5) Wrap up (10 min) AOB <NEXT CALL> March 13 (Mon): EMS scenarios, Steven's scenarios review March 15 (Wed): CDDLM-WG joint call (Dejan and Steven) March 20 (Mon): OGSA-HPC profile (Marvin) March 22 (Wed): Security Architecture (Takuya and Frank) March 27 (Mon): EMS scenarios, Steven's scenarios review, Information Model, Ellen's CIM profile review Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

Teleconference minutes - 6 March 2006
by Andreas Savva 07 Mar '06

07 Mar '06

Attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060306/en/1 (Note that April 4-7 at the Bay area was chosen again for the April F2F.) -- Andreas Savva Fujitsu Laboratories Ltd Teleconference minutes - 6 March 2006 ===================================== * Participants Michael Behrens (R2AD, LLC) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Tom Maguire (EMC) Andreas Savva (Fujitsu) Ellen Stokes (IBM) Jem Treadwell (HP) Jay Unger (IBM) Peter Ziu (Northrop Grumman) Minutes: Andreas Savva * Summary of Actions Action: Candidate hosts should check availability and facilities for F2F and report back on Wednesday's call Action: Jem will check whether there are any HP branding conditions (or formatting, logos, etc) to the webcast. Action: Hiro to add webcast preparation to the F2F agenda Action: Tom to do a final call for the WSRF BP on the list * Minutes of February 27 approved with no changes * OGSA-HPC design team update (as reported by Hiro) Marvin will be selecting a time slot for the design team teleconferences. Most of the discussion should be done on the mailing list, however. Marvin will join the April F2F by phone and may attend in person if the meeting is held on the West coast. * OGSA 1.5 (Arch and Glossary) status update Final call issued on the list. Deadline is Wednesday's teleconference in order to allow for any last minute changes and submission by the end of the week. * April F2F update Reviewed the survey results and weighted the merits and de-merits of various venues and dates. Re-selected April 4-7 at west coast (Bay Area) as the first choice. Possible hosts: - Hitachi America (Fred to check network connectivity) - IBM (at a choice of location in the Bay area) Action: Candidate hosts should check availability and facilities for F2F and report back on Wednesday's call * Webcast discussion Jem reported that HP can provide the facilities to do an OGSA webcast, including recording and archiving for later use. Features also include polls during the webcast, online chat, keeping track of number of people registering, attendind, how long they attended, etc. There are 3-4 available slots (2 hours long but can use a portion only) and depending on the date between 100-200 can participate. Participants dial in. A moderator controls the session, while people who login as presenters can control the slides. Slides must be static and should be sent in advance. Even if that was not the case it would be good to prepare and have the slides ready 1 week in advance. When scheduled HP will publicise it to other companies. It therefore has the potential to attract people that OGSA can not typically reach. So good preparation is needed. Considering the above, a date late in April is better to allow more time to prepare. The webcast preparation should also be added to the F2F agenda. Action: Jem will check whether there are any HP branding conditions (or formatting, logos, etc) to the webcast. Action: Hiro to add webcast preparation to the F2F agenda * WSRF BP status update Tom has done the edits necessary to bring the BP up to date with the OASIS Standard versions of WSRF. Action: Tom to do a final call for the WSRF BP on the list * Other business Jem has updated the front page of the OGSA-WG gridforge site with text taken from the charter. A table of already published documents may also be added. There was a discussion on whether it is worth waiting for the new version of gridforge or not. Hiro mentioned that the gridforge site may be upgraded before or at GGF17. The new site will also include a wiki. It is not clear yet whether some of the documents, e.g., glossary, should be made into wikis. (Do we want short, precise definitions as in the current document or more explanation, e.g., a page for each term?) * Wednesday call - Review information modeling guidelines (Fred) - Webcast update (Jem)

1 0

April interim F2F meeting survay
by Hiro Kishimoto 07 Mar '06

07 Mar '06

Hi all, At this Monday call, I was given home work assignment to lunch another Zoomerang survey for asking members' availability. Please take a time to answer simple questions at: http://www.zoomerang.com/survey.zgi?p=WEB2253FR68F35 We will review and decide date/location at next Monday call. Thanks, -- Hiro Kishimoto From Monday meeting minutes; > The location and dates are still unconfirmed. Agreed to a survey and > to check the results at the next Monday call. > > Action: Hiro to do a survey for the F2F location and dates. > - Simple format: date and location pairs and a yes/no choice > - 3 locations: East coast, West coast, UK (London) > - 2 dates: April 4-7 or April 10-11 (avoid Good Friday) > * April F2F agenda > > Hiro sent out a proposed agenda for the April F2F. > - (Note that the days of the week in the proposal are tentative.) > > Confirmed again that Information model and EMS (including CDDLM > discussions) are the main topics. > - CDDLM joint discussion is on the list. Dejan may not be able to > participate if the meeting is in the UK but there are other CDDLM > people based in the UK. > > OGSA-HPC: Marvin has said that he cannot make the week of April 3rd > in person. Hiro is contacting Marvin to check if he can lead by > phone, or whether someone else (Marty) can lead in person. > > Information services: no person leading this work within OGSA-WG > at the moment. (It is also identified as a 'hole' in the MS > paper.) > > Security: Frank has a clash for both the weeks of April 3rd and > April 10th. Takuya can lead the session and is talking with Frank > on work items.

1 3

GridForge test wiki page
by Hiro Kishimoto 06 Mar '06

06 Mar '06

Hi all, Just FYI GridForge will have wiki feature around (or at) GGF17! SCRM-WG is using this for their landscape document development. http://testforge.ggf.org/sf/wiki/do/viewPage/projects.scrm-wg/wiki/HomePage Username and password are different from ones for current GridForge. Thanks, -- Hiro Kishimoto

1 0

CFP: Special Session on "Service Level Agreements" at HPCC-06
by Benno Overeinder 06 Mar '06

06 Mar '06

Please accept our apologies for cross-posting. ********************************************************************** Call for Papers: Special Session on "Service Level Agreements" at HPCC-06 In distributed environments, applications often make use of pre-defined resources (and services) defined statically at the start of application execution. However, such resources may either not be appropriate or available every time execution is requested -- therefore requiring the use of a registry service to discover resources dynamically. It is also possible that resources may be owned by institutions/individuals within another administrative domain -- outside the direct control of the application manager. It is therefore necessary to make use of Service Level Agreements (SLAs) to provide the interface between application users making demands on resources, and resource providers determining what should be made available for external use. An SLA may define: (i) requirements that such an application would place on resources (and services) owned by another third party; (ii) check whether these requirements have been met during use. The complexity of an SLA can vary from a static description of resource names (specified in terms of IP addresses) to complex constraints defined as functions that can be evaluated at deployment time. The aim of this special session is to bring together researchers in high performance computing, networking infrastructure and application sciences to demonstrate how SLAs may be defined, managed, updated and used. The following topics provide some guidance on content appropriate for this special session: * Description techniques for SLAs * Static vs. dynamic SLAs * Validation techniques for SLA parameters * Matchmaking approaches for SLA comparisons * Discovering resources based on SLA descriptions * Comparison of SLA and policy descriptions * Penalty clauses for SLAs + legal issues * Managing user expectations via SLAs * SLA descriptions and Quality of Service * Multi-party SLAs * Aggregating multiple SLAs * SLAs in Virtual Organizations (both multi-party and multiple SLAs) * Negotiating SLAs dynamically * SLA-based co-scheduling and resource reservation * SLAs and Registry Services * SLA-based trust management SUBMISSION GUIDELINES Submissions must include an abstract, five to ten keywords, the e-mail address of the corresponding author and should not exceed ten pages including tables and figures. All paper submissions must already be formatted according to the guidelines for Lecture Notes in Computer Science (LNCS) and represent unpublished and original work. Manuscripts must be submitted in PDF format, usage of LaTeX as a document preparation system is strongly encouraged. Submission of a paper should be regarded as an undertaking that, should the paper be accepted, at least one of the authors will register for the conference and present the work. Submissions to HPCC-06 will be conducted electronically on the conference website. IMPORTANT DATES Paper submission: March 13, 2006 Acceptance notification: May 29, 2006 Camera ready version: June 26, 2006 Conference: September 13-15, 2006 PUBLICATION The accepted papers will be published in proceedings of the HPCC-06 conference by Springer's Lecture Note in Computer Science (LNCS). SPECIAL SESSION WEB SITE http://www.cs.vu.nl/~bjo/sla/sla-cfp.html CONFERENCE WEB SITE http://hpcc06.lrr.in.tum.de/ http://www.hpcc-conference.org/2006/ -- Benno Overeinder IIDS Group, Section Computer Systems, voice: (+31) 20 598 7634 Department of Computer Science, Faculty fax: (+31) 20 598 7653 of Sciences, Vrije Universiteit Amsterdam e-mail: bjo(a)cs.vu.nl Boelelaan 1081a, NL-1081 HV Amsterdam

1 0

Proposed agenda for March 6th call
by Hiro Kishimoto 06 Mar '06

06 Mar '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 6th Monday from 4pm to 6pm (CST). The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0306 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (Feb. 27) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060227/en/1 OGSA-HPC design team status update (if available) Agenda bashing 2) Document status (20 min) OGSA WSRF BP 1.0 status (Tom) OGSA 1.5 status (Andreas) 3) April F2F meeting schedule (30 min) We will decide date and location at this call. If you don't answer zoomerang survey yet, please take a time to answer simple questions *NOW* : http://www.zoomerang.com/survey.zgi?p=WEB2253FR68F35 F2F session proposal; https://forge.gridforum.org/projects/ogsa-wg/document/200604F2F_session Survey result as of Today (14 answers). https://forge.gridforum.org/projects/ogsa-wg/document/200604_Survey 4) OGSA Webcast (30 min) Jem and HP are kind enough to offer Webcast facility for OGSA-WG. These are our current options: * 4/11/2006 12:30 PM - 2:30 PM Eastern * 4/19/2006 11:30 AM - 1:30 PM Eastern * 4/26/2006 1:30 PM - 3:30 PM Eastern The timing of these are good, as we can either work on something at the f2f or even, if the f2f is the week of 4/10, do it *from* the f2f - provided we had good phone facilities. 5) Wrap up (10 min) AOB <NEXT CALL> March 8 (Wed): Information Model, Fred's guideline review March 13 (Mon): EMS scenarios, Steven's scenarios review March 15 (Wed): CDDLM-WG joint call (Dejan and Steven) March 20 (Mon): OGSA-HPC profile (Marvin) March 22 (Wed): Security Architecture (Takuya and Frank) Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

OGSA wikipedia entry
by Treadwell, Jem 03 Mar '06

03 Mar '06

Hi, Andreas and I have had a long-standing action to update the OGSA entry in wikipedia, and I've recently completed a series of updates to it, to bring it into line with our documents. You can see the history of the changes - basically, the first two and last two paragraphs were there when I started, but I've modified them significantly, and the bit in the middle comes from the Roadmap and Architecture documents. My goal was to provide a brief outline, but let the documents provide the detail, so that it can be updated easily as the documents progress. I'm not looking for comments: if you think something needs changing, it's a wiki, so just go ahead and change it. I have a watch on it and will try to keep it up to date if nobody else gets there first, but I'm *not* claiming ownership, in any sense of the word. :0) And on a closely related topic, I notice there's a recently-added CDDLM entry (also nice and brief). - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com>

1 0

April F2F meeting session proposal
by Hiro Kishimoto 01 Mar '06

01 Mar '06

Hi all, Please find proposed April F2F meeting sessions attached. It is also uploaded to GridForge: https://forge.gridforum.org/projects/ogsa-wg/document/200604F2F_session > * April F2F agenda > > Hiro sent out a proposed agenda for the April F2F. > - (Note that the days of the week in the proposal are tentative.) > > Confirmed again that Information model and EMS (including CDDLM > discussions) are the main topics. > - CDDLM joint discussion is on the list. Dejan may not be able to > participate if the meeting is in the UK but there are other CDDLM > people based in the UK. > > OGSA-HPC: Marvin has said that he cannot make the week of April 3rd > in person. Hiro is contacting Marvin to check if he can lead by > phone, or whether someone else (Marty) can lead in person. > > Information services: no person leading this work within OGSA-WG > at the moment. (It is also identified as a 'hole' in the MS > paper.) > > Security: Frank has a clash for both the weeks of April 3rd and > April 10th. Takuya can lead the session and is talking with Frank > on work items. > > The location and dates are still unconfirmed. Agreed to a survey and > to check the results at the next Monday call. > > Action: Hiro to do a survey for the F2F location and dates. > - Simple format: date and location pairs and a yes/no choice > - 3 locations: East coast, West coast, UK (London) > - 2 dates: April 4-7 or April 10-11 (avoid Good Friday) -- Hiro Kishimoto

1 0

Proposed agenda for Feb. 27 call
by Hiro Kishimoto 01 Mar '06

01 Mar '06

Hi all, ** MONDAY TELECONFERENCE DIAL-IN HAS CHANGED FROM THIS WEEK ** The following is a proposed agenda for OGSA-WG telecon on Feb. 27 Monday from 4pm to 6pm (CST). The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0227 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (Feb. 22) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20060222/en/1 Agenda bashing 2) Document status (20 min) OGSA WSRF BP 1.0 status (Tom) OGSA 1.5 status (Andreas) 3) April F2F meeting discussion (30 min) Decide the main topics for the April F2F agenda. Attached is the proposed topics. > The week of April 3 also needs re-confirmation since some people > have said they may not be able to make it. 4) Weekly telecon schedule up until GGF17 (20 min) 5) Wrap up (10 min) AOB Thanks, -- Hiro Kishimoto

1 2

No OGSA-WG call on this Wednesday (March 1st)
by Hiro Kishimoto 01 Mar '06

01 Mar '06

Hi all, We agreed to review OGSA WSRF BP 1.0 re-submission status on this Wednesday but I have not yet talk to Tom. Thus I propose to have NO call on this Wednesday. Next OGSA-WG call will be Monday March 6th. Thanks, -- Hiro Kishimoto

1 0

RE: [ogsa-wg] New OGSA-HPC design team - Call for Participation
by Subramaniam, Ravi 28 Feb '06

28 Feb '06

Hi, Please use the template that has been put together by the EGR-RG. This is based off of the original OGSA template and can serve to help both the OGSA work and work of other WGs in GGF. We agreed that the EGR would maintain the OGSA use cases as part of the larger collection and collation of GGF and Enterprise Grid use cases. We are also in the process of working with EGA owners of use cases to migrate/provide their use cases into EGR too. Here is the link to the template: https://forge.gridforum.org/projects/egr-rg/document/UseCaseTemplate-r0. 2/en/1 Thanks! Ravi -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Hiro Kishimoto Sent: Friday, February 24, 2006 6:55 AM To: Stephen.Pickles(a)manchester.ac.uk Cc: OGSA WG Subject: Re: [ogsa-wg] New OGSA-HPC design team - Call for Participation Hi Stephen, > Would now be a good time to dust this off? I believe so. > Is there a new template? Last time round I had difficulty > relating the use case in the terminology requested, > which was then rather immature. New template should be one of initial discussion topic for this new design team. We now have OGSA glossary and I am pretty sure it helps a lot to understand terminologies. Marvin: You can find the latest (but rather obsolete use case template) here: Thanks, ---- Hiro Kishimoto Stephen M Pickles wrote: > The RealityGrid use case in the OGSA Tier2 UC document > is also very HPC-oriented. > > Would now be a good time to dust this off? > > Is there a new template? Last time round I had difficulty > relating the use case in the terminology requested, > which was then rather immature. > > Stephen > > > > >>-----Original Message----- >>From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On >>Behalf Of Hiro Kishimoto >>Sent: 23 February 2006 23:14 >>To: OGSA WG >>Subject: [ogsa-wg] New OGSA-HPC design team - Call for Participation >> >>Hi all, >> >>At the GGF16 OGSA-WG F2F meeting on Friday, we have discussed and >>agreed to form new OGSA-HPC design team. >> >>This design team will focus on the following; >> >> 1. Refine and analyze the HPC job submission use case (input from >> the existing one and other sources, including whether >>it covers >> the necessary functionality); and >> 2. Review existing specs; and >> 3a. If new specs are needed then launch activities to define the >> needed specifications; otherwise >> 3b. Try doing such a vertical profile possibly in a different WG. >> >>OGSA-HPC design team is open for everyone and will use OGSA-WG mailing >>list the same as the other design teams. If you are interested in >>this design team, please contact Marvin <theimer(a)microsoft.com> or me. >> >> From the F2F minutes. >> >>> ACTION: Marvin to start and lead a design team within OGSA-WG to >>> work on the HPC use case immediately. >>> - It should be advertised to the OGSA list >>> - There is an existing use case within OGSA-WG and it >> >>should be used >> >>> as input. (Ravi's use case from the OGSA UC Tier 2 document, >>> already sent out to the list.) Other input will also be >> >>solicited. >> >>> - Allocate time on the ogsa call periodically for a status review >>> - Potentially do a BOF at GGF17, if the scope is clearly >> >>defined by >> >>> then >>> - The design team to be named OGSA-HPC >> >>Presentation at F2F meeting (MUST READ); >>https://forge.gridforum.org/projects/ogsa-wg/document/GGF16-F2 >>F-Evolutionary-Approach >> >>Paper proposing "evolutionary vertical design efforts": >>https://forge.gridforum.org/projects/ogsa-wg/document/An_Evolu >>tionary_Approach_to_Realizing_the_Grid_Vision >> >>Meeting minutes; >>https://forge.gridforum.org/projects/ogsa-wg/document/ggf16-f2 >>f-minutes-20060217 >> >>Thanks, >>-- >>Hiro Kishimoto >> >> >> > > > >

1 0