OGSA PE focus session - November 10, 2003 ========================================= * Participants Daniel Templeton (SUN, DRMAA) Chris Smith (Platform) Hiro Kishimoto (Fujitsu) Hrabri Rajic (Intel, DRMAA) Ravi Subramaniam (Intel) Takashi Kojo (NEC) Andrew Grimshaw (UoV) Andreas Savva (Fujitsu) John Tollefsrud (Sun) Ming Xu (Platform) * Next calls Agreed to skip next Monday's (11/17) teleconf, since many folks will be going to SC2003. Next call: Nov. 24 (Thanksgiving week) Next+1 call: Dec 1 (F2F week) * Actions: Action: Andrew will provide WebEx to general session too >Thanks Andrew. Action: Hiro to send his notes to Andrew. >Thanks Andreas for your help. Action: Andrew, by next meeting, to draw up list of services together with example composition(s). Action: Andrew to summarize today's discussion from both sides in a short document and circulate it to the OGSA-WG. ...more... * Background In the last teleconf DRMAA & Platform proposed getting something out of the door quickly and so focus on PE (platform's proposal) only. Last week's teleconf consensus was for a two phase approach - short term: PE (platform's existing proposal) - long term: generalize (Ravi's proposal) Ravi: It is easier to start with a clean slate and make sure that legacy stuff are supported rather than starting with existing legacy sutff and refactoring. Wrong focus might lead to wrong direction. Andrew: Last time we decided that we had to study existing proposals and discuss them once again. In particular read - DRMAA specification - Platform's submission to OGSA document Andrew: After reading Ravi's and Ming's submission I realized that the two proposals are not mutually exclusive. No disagreement. Andrew: DRMAA provides an API to monitor, control jobs. It separates clients from the details of different platforms. DRMAA is not so relevant to the architecture because it is mainly an API. The API is also used for DRM systems, but it is not have strong impact OGSA. Andrew: We need resource model to handle DRM. Does CMM fill this niche? Hiro: CMM is not working resource model but management model. Ravi: CMM i/f might map to DRMAA i/f to operate on the DRM. E.g., DRM is described by CMM and under CMM there are DRMAA. CMM is general management model and DRMAA provide resouce model. Q: CMM is ws-agreement based? A: No. CMM covers basic manageability requirements. So a resource should have CMM portType and WS-Agreement portType. Chris: There's a control port for job/reservation/etc. Separate management port extends CMM's portType. Andrew: Job proxy/queueing service/data service etc in platform document. Interesting that it also includes data service. Chris: This could be something defined by DAIS, etc. Andrew: So CMM would wrap all of these [PE services]? Ravi: No. Each is a separate service. And management is different portType. Andrew: Platform already has done some kind of factoring. They have a couple of different services for legacy applications. Question for platform guys. Is it possible to refactor and add more services? Chris: No objection to further refactoring and to adding more functionalities. We have a lot of experience in supporting legacy apps. Many customers are asking platform to provide OGSI i/f. Andrew: We are not talking about OGSI i/f here. Ravi: Many people confuse OGSI and OGSA. Platform's goal is not OGSI compliance. OGSI is just web services. There are a lot of interfaces. But they are not yet standardized. Andrew: Two comments. 1) Clarify what ogsa architecture is 2) Refactor platform proposal by adding services. Not just a straight refactoring. We want to introduce more functionalities. Ravi: Once our document is published, many people will create their systems based on it. It will be more difficult to change things later. Ming: I am very sceptical on an approach based on deriving new things from existing usecases. It may lead us in wrong direction. Andrew: I will summarize today's discussion from both sides in a short document and circulate it to the OGSA-WG. This discussion is very important. People not on this call should also be aware of it. Platform proposal is very important but I want to do more complete job (architecture). I think we can add things, such as deployment service, etc. ... Andrew: I have a document. (Uploads doc and goes through it). Chris & Ming: We've already done this kind of work for CFS. Ravi: There are many capabilities within existing products. Not a stovepipe solution. Break down into services to expose capabilities. ... Who is apps developer? Ming: ISV Who is audience of the OGSA doc? ISV is not. ISV will use high level API (e.g., DRMAA) only. Ravi: I disagree. ISV may chose high level API like DRMAA or contact scheduler directly. Composition is very important. End result is more than the set of components. It is very important design principle. Each composition might be what we used to call profile or view. (Might still be in OGSA doc.) Andrew: By next meeting, I will try to list services together with example composition. Refactor making sure that legacy systems can also be supported. Andrew: All service [factories] are WS-Agreement based. I am not sure what CMM will provide. Hiro: CMM provides very basic (low) interfaces/constructs. CDDLM will provide higher level functionality such as deployment and configuration portTypes. Andrew: I should attend CMM teleconfs since people often give me conflicting information about CMM. Some people talk about meta-data aspects.