OGSA F2F - Oct 6, 2005 ====================== * Participants Hiro Kishimoto (Fujitsu) Andreas Savva (Fujitsu) Donal Fellows (University of Manchester) Dave Berry (NeSC) Steve McGough (Imperial College) Chris Smith (Platform) William Lee (LeSC) Philipp Wieder (Forschungszentrum Julich) Abdeslem Djaoui (Rutherford Labs) Toshiyuki Nakata (NEC) Fred Maciel (Hitachi) Steven Newhouse (OMII) Stephen Crouch (OMII, University of Southampton) Ellen Stokes (IBM) Dejan Milojicic (HP) Jay Unger (IBM) Mathias Dalheimer (Fraunhofer ITWM) Wolfgang Ziegler (Fraunhofer) Takashi Kojo (NEC) Jun Tatemura (NEC) Steve Loughran (HP) Ayla Debora (Universidade Federal de Campina Grande) Michael Behrens (R2AD, LLC) Stuart Schaefer (Softricity) Sachiko Wada (Ascade) Allen Luniewski (IBM) Andrew Grimshaw (University of Virginia) Tom Maguire (EMC) Manuel Pereira (IBM) Jem Treadwell (HP) Tom Roney (NCSA) Minutes: Andreas Savva * Agenda Bashing Hiro proposed a revised agenda for the CDDLM-EMS which was accepted as a starting point. https://forge.gridforum.org/projects/ogsa-wg/document/GGF15-F2F-EMS-draft/en/1 ** Requirements with priority (for EMS) - Not clear what agreement based means in the context of job types; needs more refinement. - Agreement: framework and vocabulary to describe requirements - Agreed to review WS-Agreement to evaluate its position. ** WS-Agreement introduction Presentation: https://forge.gridforum.org/projects/ogsa-wg/document/GGF15-F2F-WS-Agreement-Introduction/en/1 - Mutual agreement or 1-way agreement? Can an agreement also bind the initiator? - It might depending on the terms. But the protocol only says that the responder agrees or not. - In that case who observes what? - How is an Agreement used after created? Domain specific. - But OGSA might have to define a specific interaction pattern for creation and use. - In some cases agreement-creation may be equivalent to job submission; in others it might be done as separate steps. As separate steps we need to define the relation between those steps. - Agreement is then a resource allocation(reservation) - And passed in as additional information in a createActivity step - Why is the Agreement represented as a WS-Resource? Why not a signed document? - More broadly, how it is represented and referenced? - And implications on multi-part agreements (requirement?) - Recording the allocation of resource and the requirement to manage its lifetime leads to the requirement to model an Agreement as something like a WS-Resource. - Two-phase commit protocol requirement - And whether it is a requirement on WS-Agreement in general or WS-Agreement application to EMS. - Since it is explicitly WSRF-based what are implications if there are other basic profiles? - WS-Agreement and relation with WS-Policy: None. But it could be combined with WS-Policy. Action: Set up a team to explore WS_Agreements issues more, especially relating to allocation and QoS assurance. And come back to OGSA-WG on how to use WS-Agreement (possibly evolved) with EMS. Clarify - How WS-Agreement possibly needs to change to fit in OGSA EMS - Set the first review after 30 days; check what can be done. - Volunteers: Steven Newhouse (to lead), Dave Berry, Chris Smith, (Jim Pruyne; not present >GRAAP-WG to confirm) - (Others also planning to explore use of Agreement) - GRAAP-WG is also planning to submit requirements document - WS-Agreement spec has been re-submitted to the GGF Editor but has not yet entered public comment. ** Deployment and configuration requirements CDDLM: provisioning of any type of resource but from the point of view of an application (the needs of the application) - from some level down (the (CDL) tree) might be more static or can appear as a given or pre-provisioned. - The place where that 'line' is drawn is an abstract notion which may be based on a number of factors: e.g., the cost of provisioning, or the available number of resources, or... - The 'line' might also depend on the definition of the system. But CDDLM does not do resource allocation; the resource is allocated (by the scheduler) and CDDLM's job is to configure what it's given. - Points towards a requirement that an estimate of how long a configuration might take is needed to be passed between a scheduler(EPS) and the CDDLM engine. Such information is not part of CDDLM at the moment. (Not sure if this is some information that is best provided from 'provisioner' or exists somewhere in the system.) - Agreed that there is a requirement to provide an estimate of how long the configuration takes. - This information may be history based and may have to be updated/recalculated dynamically. There may be additional information on quality of estimates. - Proposal to do exploratory work on how to map CDL to CIM and JSDL to CIM (information model) and how these relate to each other - (And to the representation of the state of the system) - And scheduler and provisioning decisions may be driven by some shared view of these. - In some models the CDL may be generated from CIM (also using some additional information) - Part of this work is to be done by the RM team (e.g., which profiles are needed within EMS) - And provisioner-scheduler interactions will be explored in a separate session - Action: CDDLM team volunteered to look into two issues that were identified as requirements and report back in an OGSA call 1. Where to draw the line in the (CDL) provisioning tree (see above) 2. How to provide the cost of configuration - Optimization requirements: Agreed this is lower priority - Proposed that as part of prioritizing requirements might be worth defining an EMS roadmap and which functions (and how far) are defined when. (see later on for proposal) - Discovery: lower priority but keep on the list (need to define interfaces) ** Scenarios review *** Stuart's presentation of scenarios Stuart's presentation on CDDLM, ACS and EMS scenarios: https://forge.gridforum.org/projects/ogsa-wg/document/GGF15-F2F-OGSA-CDDLM-ACS-scenarios/en/1 - One proposed scenario is not to have ACS 'hidden beind provisioning/deployment but to locate it behind information services or data services - Initial diagram shows CDDLM call ACS directly (ACS::GetContent). This implies a relatively tight coupling of the two. The proposal is to decouple these further. - Issue: What are the interfaces that would then be required of EMS? - Interactions with container still driven by CDDLM. - There is still model mismatch between EMS and CDDLM, exacerbated by using similar terminology with different meanings. - Action: Agreed on two-pronged approach for CDDLM(+ACS) on one side and EMS on the other to describe their approaches in more detail and to then unify those approaches. (Note these are 3 separate actions.) *** Andrew's review of EMS "Legacy application" scenario - A sample scenario but not all interactions are necessary (returned data is not discussed during meeting). Worked to add step numbers. (This was also refined further at the end of day 2.) Jay's copy: https://forge.gridforum.org/projects/ogsa-wg/document/GGF15-F2F-EMS-CDDLM-ACS-Numbered_sequence/en/1 - Sequence of steps: 0. (submit job request to) JM 1. JM - jsdl' -> EPS 2. EPS - jsdl' -> CSG 3. CSG - accesses - {Information services, ACS} (to possibly augment information in the jsdl doc) 4. CSG - candidate sets - EPS 5. EPS - schedule - JM ** Proposed EMS Roadmap Steven N's proposal to draw up EMS Roadmap and thereby decide the order in which to define the necessary functions. Outline here: - 0.1 BES Container + Simple JSDL Activity - 0.2 0.1 + Delegated JobManager+Monitoring - 0.3 0.2 + RSS - 0.4 0.3 + IS - 0.5 0.4 + CDDLM to BES - 0.6 0.5 + CDDLM to Application - 0.7 0.6 + ACS - 0.8 0.7 + Allocation & Reservation - 0.9 0.8 + Accounting - 1.0 : The entire EMS(tm) Action: To expand the above to a one paragraph description for each bullet (Steven N). Done and draft uploaded: https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap/en/1 * OGSA Naming Review of 3-level naming scheme 1. Human (e.g., RNS) ----------------- 2. Abstract (e.g., WS-Names=AbstractName+EPR) ----------------- 3. Addresses (e.g., EPR) This is essentially a 2-layered architecture since 2 & 3 are essentially implemented in the same way (EPRs). - Proposal to have all references as EPRs and make more specific statements depending on context whether they should be decorated with an AbstractName. - References to services (parameters or returns) are EPRs or RNS names (something hierarchical). Or, is this anything (e.g., URI) that can be converted to an EPR? - For RNS would also need to pass in context or resolver(?) The group went through the exercise of doing a number of straw polls to identify the weight people put on various approaches. <> - Agreed that we can choose MUST - 1. MUST EPR (majority yes; no negative votes) - passed - 2. MUST {EPR or URL} (yes:2; no:many) - rejected - 3. MUST {EPR or RNS} (yes:0; no:many) - rejected - 4. MUST EPR be WS-Name (yes:; no:) - rejected - 5. SHOULD EPR be WS-Name (yes:; no:) - ? - 6. RenewableReferences: MUST, SHOULD - rejected - 7. RenewableReferences: MAY - passed In summary: "MUST support EPRs, may support WS-Names or RRs or other things" It seems to depend on the situation whether to use something beyond an EPR. Need more exploratory work to identify which areas would benefit from using WS-Names or RenewableReference. - Proposal to also just say they are EPRs that may be decorated (and hence be WS-Names) Action: WS-Address WSDL binding writeup on how it can be used to provide functionality similar to WS-Names. - (Tom volunteered to do this by the end of the week. Done.) - Is an AbstractName needed as a separate field or is the WSA Address (To) field a URI and so can serve the same purpose? - Tooling assumes or implements as URL (this is a strong reason to define something else) - Spec says or recommends URI but does not mandate it - So a profile would still be needed to define what a WS-Name is - RNS document status: in 3-week GFS-WG internal review. Will also do a more general call and then submit to the GGF Editor. - WS-Naming: reviewed during GGF15. One change agreed on (allow multiple resolvers) and will then submit to GGF Editor. * Resource Management ** Review of Ellen's Approach slides https://forge.gridforum.org/projects/ogsa-wg/document/information_modeling_approach/en/1 - Recap of Information and Data Model definitions - Profiles would be defined and owned by GGF but the model custodian is DMTF - Profile work is collaboration work---driven by the owning group and assisted by RM design team. - The concern is still that CIM is very big and it is not clear how doable this work is. - Need to get an indication of how 'heavy-weight' this work will be. - Ellen is doing some exploratory work to show what's involved - It was emphasized that doing a mapping of the various data models (JSDL, GLUE, etc) to the CIM information model doesn't mean that those data models go away (at least not in the short term). ** Container presentation (exploratory mapping work): https://forge.gridforum.org/projects/ogsa-wg/document/containers_and_BES/en/1 - Reviewed Ellen's initial work to map the OGSA (not necessarily a BES) definition of Container - Still OGSA container definition is too 'abstract' or not clearly understood. - Agreed to do a BES container profile as initial example - Textual description of classes and UML diagram (annotated in such a way that their provenance is clear: CIM, GLUE, ....) - Volunteers: Andrew Grimshaw, Ellen Stokes, Chris Smith - Also need access to a Glue expert: Email Steven N and Sergio ? - Or the glue-schema mailing list. - Steven is the initial contact for Ellen * Re-charter discussion Latest draft: https://forge.gridforum.org/projects/ogsa-wg/document/OGSA-WG-new-charter-draft/en/3 - Considered and rejected changing OGSA-WG to OGSA-RG. - Updates per Hiro's copy of the Charter. - Reconsider teleconference time slots; possibly a shifting schedule. * OGSA 1.5 - Reviewed information services draft by Abdeslem. - Andreas will merge in to the next draft.