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

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