OGSA January 2006 Interim Meeting ================================= Sunnyvale F2F, 17 January 2006 PM Attendees --------------- Mark Morgan (Minutes) Hiro Kishimoto David Snelling Fred Maciel Jay Unger Jem Treadwell Dave Berry Stephen Newhouse Allen Luniewski Takuya Mori Andrew Grimshaw Tom Maguire Ellen Stokes Chuck Spitz Fred Brisard (*) Darren Pulsipher (*) Andreas Savva (*) Steve McGough (*) Jim Pruyne (*) Bridge: Marvin Theimer (+) Savas Parastatidis (+) Marty Humphrey (+) Glenn Wasson (+) (*) OGSA 1.5 session onwards (+) WS-Management only * WS-Management ** Looks like there might be a reconciliation between the various camps (WS-Notification, WS-Eventing, WS-Management, etc.) - Still in a state where we aren't sure where it's going, but people optimistic - How does this influence the working group - What does it mean to have more then one protocol stack - May be premature to do something now when the reconciliation may be coming down the pipeline. -- We might want to wait for a few months on deciding what this working group is going to do. - Are you talking about WS-CIM, or more then that? -- Specific things laying WSRF and WS-Notification on top of the base protocols Microsoft has proposed - What do you think the form of reconciliation will be? -- premature to make any kind of a statement. - What do you mean by reconciliation? -- Isn't useful unless it turns into something that people can use in terms of standards -- a way of doing things. - At what point do we (OGSA-WG) attack a profile? Now, or hold off for a period of time. How important is that to the people who will be working on it? -- Marvin thinks the right thing to do is to wait a couple of months (timebox it) - Marty says "We're not holding here" -- We're trying to look at what the reconciliation might be -- Trying to anticipate this reconciliation -- Trying to study BES and ByteIO and see how the reconcile stack applies to these two services -- Trying to do something productive - Exploring the questions of What-if is good - Can we proceed or not? - Does WS-Man make much sense in terms of Job Management - Well, except for obvious stuff like job status. ** Status Report from Marty's Group Conclusion is that if there isn't any significant change, we'll discuss again around GGF in Tokyo - Marty's group to continue investigating - many interesting things they can do. - This seems like the discussion we had about whether to use OGSI or not. - That went away and we decided to use WSRF * OGSA 1.5 review Led by Andreas Savva - Andrew to get Naming section to Andreas tomorrow after naming discussion. - Changes as per the document - A number of references removed from text and put into footnotes. - Can't mandate that transactions are honored. - Andrew wants to note that we should talk about a way of keeping places to talk about things like calling context. -- WS-Context not the same as that is a service that you can go to to get context, not something carried along with messages. - Need an Orchestration sub-section (along the same lines as Transactions) - Choreography and Orchestration do have different meanings. What's the difference here? The terms are defined in the Glossary also. - Figure 4 for EMS is misleading. Posing a lot of confusions for people. -- General consensus is to remove the figure (Removed) - Can we fold in the stuff we talked about today into the Deployment and Configuration Service section? -- Leave it where it is, with added reference to the Self-management: Provisioning section. - Do we want to update Figure 5? - Get rid of arrow from Job Manager to Service Container - Change Accounting Services to Logging - Do we want to put a sequence description (add step numbers) - Could also expand the Provisioning box - Dave B is also working on revising the Data section "Interactions with the Rest of OGSA". * Glossary review Led by Jem Treadwell. - Discussed definition of Resource and made a number of revisions. - RFC 2396 has been superseded by RFC 3986 * WS-Agreement Overview for OGSA (GRAAP-WG) Presentation by Jim Pruyne - Update about what has happened since the last time presented - Public comment, round 2, complete - If you want to start using WS-Agreement, you don't have to change what you are already doing though there may be some benefit to combining the two together. - You pass in a document, get back an EPR - How would we use this in EMS? We decided to punt for BES. Now that we have BES, one can imagine defining a service that exports an Agreement like interface that wraps a container. On the other hand, you can use the EGEE approach and go a little higher (job manager) and do it. - Agreement adds some notions to standard stuff like times. That and guarantee terms. - Guarantee terms leads to the problem of specifying the QoS things that you are guaranteeing, how do you measure failures, etc. - What can BES do with WS-Agreement that would add value. -- Seems like we should start a new WG to define QoS terms for job delivery and how do you characterize penalty terms. -- That should be out of scope of BES and the Data areas. - Summary -- We need more studies -- Just JSDL and WS-Agreement does not provide clear benefit -- Can we build on the consensus from this morning -- We have a situation where we said that the lower level CDDLM provisioning underneath the container is something that the container, given that is advertising capabilities, is something that the container would like certainty about. It might not be a bad idea to have an agreement to that affect. -- It is NOT the case that everyone who has tried to do something with Agreement has done it with the same term space. -- WS-Agreement supersedes WS-Policy -- Going to investigate applicability of WS-Agreement -- An interesting application that has a natural fit here is Security. Dave S will discuss this proposal with the Security team on Thursday.