OGSA Interim Meeting (GGF16) ============================ Location: NTUA, Athens, Greece Date: 17 February 2006 * Participants Dave Berry (NeSC) Keisuke Fukui (Fujitsu) Hiro Kishimoto (Fujitsu) Steve Loughran (HP) Fred Maciel (Hitachi) Steve McGough (IC) Dejan Milojicic (HP) Mark Morgan (UVa) Takuya Mori (NEC) Steven Newhouse (OMII) Darren Pulsipher (Ovoca) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Ellen Stokes (IBM) Ravi Subramaniam (Intel) Marvin Theimer (Microsoft) Jem Treadwell (HP) Jay Unger (IBM) Minutes: Andreas Savva (text also contributed by Jem Treadwell) * Summary of Actions [For more details and context see the body of the minutes] 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 ACTION: Tom and Andreas to discuss the April F2F agenda at the next call ACTION: Hiro to launch a survey (Zoomerang) for location after the agenda is set. 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 ACTION: Hiro to send mail to GIN group and cc OGSA-WG. ACTION: Ellen and Fred to do a document draft that includes - JSDL-CIM mapping - resource container attribute mapping - relationship table in CIM - And to be reviewed by various people (Steven N, Darren, etc) - It would also be really useful (perhaps at a later point) to also show the correspondence of GLUE with the above. * CDDLM joint discussion A JSDL BLAST example was posted to the list prior to GGF16. Steve Loughran introduced a CDL example 'corresponding' to the JSDL one. This immediately raised a number of questions on the approach taken: - What should the correspondence or relation between a JSDL and CDL document? One could encapsulate the other; or there could be a reference relation. - What is the added value of using CDL? There is not much point in simply duplicating the functions in the JSDL document. It was agreed that the CDL document should not just reproduce the JSDL document but it should instead provide a more detailed description of what needs to be set up to make it possible to run the job described by the JSDL document. - In part this is drawing the line between the deployment and provisioning. - As a general approach it was also agreed out that we should aim for a relation such that 'moving the line' between deployment/provisioning should not affect the contents of JSDL and CDL documents. (There was also a repeat of the Sunnyvale (Jan 2006) discussion. That is whether configuration actions should be done implicitly by the container vs making them explicit. Re-affirmed the consensus that configurations actions should be made explicit.) How close is CDL to be a declarative vs procedural language? Agreed that it can probably be used either way, but with a preference towards a declarative use for OGSA purposes. Proposal to work out details in a smaller group with people from the various groups (JSDL, BES, CDDLM) before bringing it back for an architecture review. - Accepted in principle, but was put aside in favor of the following action. 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 * Next Meeting discussion ** Interim Meeting at GGF17 Discussed options for a Monday, Tuesday or Saturday F2F. Or a combination of the above. Since there is an April F2F also planned it was felt that spending more time at this point would not be productive. Consensus (7 against 3) to NOT having a one-day F2F at GGF17. ** April Meeting Went through a series of straw polls, not reproduced here with the following results: - A four day meeting - April, Tuesday-Friday (4/4-7) are the best dates - San Francisco preferred over London by a small difference - And many people expressed a desire to reconsider - Agreed that the choice of venue should be reconsidered after fixing the agenda and based on the availability of the people required by the agenda - Agreed to make a final decision by March 6 to allow sufficient time to book flights etc. ** Teleconferences - No Monday call - Wednesday call to set agenda for April F2F ACTION: Tom and Andreas to discuss the April F2F agenda at the next call ACTION: Hiro to launch a survey (Zoomerang) for location after the agenda is set. * Proposal for HPC Grid Profile Proposal is for "vertical profiles" in addition to current (horizontal) work. Described in a document that was sent out to the list. - Main scenario: Remotely executing a program on a compute resource - Avoid more complex functionality such as provisioning and ... - Use non-controversial specs (defer discussion on WSRF vs WS-I; WSDM vs WS-Man) Proposal discusses 1) design principles of how to build things up 2) the contents of what should be built - This is a concrete use case. The desire is to see how things already fit but there is no urgency (and no immediate proposal) to go off and change the architecture. - What is a non-controversial spec? The basic idea is to built on what is stable. (It was pointed out that the Profile Definition goes into some detail on these definitions and should be used as a measuring rod.) - There has been a lot of horizontal work. This kind of vertical work is a way to validate the horizontal work ('close the design loop'). Probably/hopefully all the specs that are needed are available; otherwise things become much more complicated. - Doing this kind of vertical work might cause some re-design of the initial factoring. And a number of iteration are probably necessary. (In any case the vertical work should be implemented and tried out before iterating further.) - It was also pointed out that the OGSA documents 'big picture' includes this kind of iterative process. - The iteration cycle should be relatively short to keep the work current. - OGSA does not seem to have the expertise in all the various verticals mentioned to define this kind of vertical profiles. - Someone has to do it. And it is not clear if the work should be done inside OGSA or not. - How do these vertical profiles relate to the horizontal ones. For example, how do they evolve together? - The process discussion is an important one but the group should not get too bogged down by that. People are building stuff and will make decisions regardless since they have to ship products. - There is a use case for HPC job submission in the OGSA Use Case Tier 2 document. This was submitted by Ravi S. Discussed whether this should be the basis for moving forward on this topic. - Agreed on a process proposal for moving forward: 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. It was re-stated that a profile has to use existing specs (mini specs can be defined on the fly). And that there is a design effort to check whether the necessary functionality is available. This design effort could start as a design team to explore what needs to be done; with the option of starting a new WG once there is a clearer understanding of what pieces exist. The alternative is to divorce completely from OGSA-WG and do this activity separately. But in the latter case there would probably be more discussion within the GFSG on whether such a clearly overlapping effort should be allowed. 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 On a side note the WS-Management profile for OGSA was also discussed: - Can there be a WS-Man profile for OGSA at the same level as the WSRF BP and thereby a way to make sure that the multiple basic profiles approach actually works? And could there be Microsoft participation to this? (This work wouldn't go the distance to management (WSDM level) which is more controversial.) - If scoped to a narrow enough domain it might be worth trying; it is difficult to see what it means for doing it for the whole of OGSA. - This is a different issue from the vertical profile proposal but nevertheless an important one. - WS-Man profile: Dave S, Jay and Tom M have an open offer to assist a design team defining this - Missing some experts for individual specs * Information Services Currently no activity in info services. - Steven: There's an activity going on in GIN (Grid Interoperability Now) to identify endpoints - GIN/OMII will develop its own information service - GLUE/CIM-based - Hiro: Any chance we can get them to join our calls? - Steve: Unlikely; we would need to join theirs. - Ravi: Collect info from other documents, such as MDS. - Steven: OMII is going to be very focused on their work for the next six months, and won't have time to write documents to feed back to OGSA. - Dave S: There's an enormous amount we can learn from them - might want to ask for a summary document, one chapter per area. We need to keep Charlie Catlett & Dane Skow informed; ACTION: Hiro to send mail to GIN group and cc OGSA-WG. * RSM license update - Process kinks worked out. - Use the online form to apply. Allow for 3-5 business days for completion. * Information model discussion - A list of use cases as requested at the last GGF session is needed. - Given a data model (right or wrong) can it be mapped to the information model? - Some people agreed (and none disagreed) with the statement that "the JSDL implied model has a mapping to the information model" - A JSDL to information model (CIM) mapping and the relationships in CIM provide a way to 'select' a resource model for bes container. So that a JSDL description can be matched with a container description. ACTION: Ellen and Fred to do a document draft that includes - JSDL-CIM mapping - resource container attribute mapping - relationship table in CIM - And to be reviewed by various people (Steven N, Darren, etc.) - It would also be really useful (perhaps at a later point) to also show the correspondence of GLUE with the above. - There is going to be a GIN information model discussion at GGF17 and Fred & Ellen should plan to attend. * OGSA 1.5 & Glossary update - Documents are close to final call. The Glossary is done, the architecture document needs some minor changes; some to address issues raised during GGF16. - A final call probably sometime next week. - Andreas will put both glossary and architecture into final call - Proposal to make the glossary into a wiki to make it easier for more people to contribute. And freeze occasionally for publication. * OGSA Communication - Agreed to a presentation per capability in addition to a high level presentation. - Presentations should be against published material, not the latest state of the work, to make it easier for people to find additional information.