OGSA EMS Scenario Discussions Session ===================================== * Participants Oakridge, Jim Renolds joined part way through, otherwise, the F2F attendees plus Zac by phone. Decision: Dinner at 630, by consensus. Discussion based on S. Newhouse's email, see below. Initial discussion: - Status of CDDLM: The new chairs will draw up the experiences document. - Status of ACS: Published with implementations, but the group is dormant. Overall question: Where should we go next with EMS Architecture Scenarios? - The architecture references a number of specifications some of which are drifting out of use. - These should be removed from the EMS specification and the architecture adapted as needed. Topic 1: Guiding Principles - Agreed New Principle: Allow specs under development (or even new) to be included, but documented as such in the spec. - Guidance was provided that the chairs of referenced specs should be consulted on the inclusion of their spec. - Current Principle: Published specs only, with a special exception for RSS. - How often do we revise the document? - New version once a year, but work on it for only the six months leading to publication - Schedule: Draft: Nov 2007; PC: Feb 2008; Apr 2008 Topic 2: Scenario Review To add: - Need to add data staging to the document, probably as a new chapter. - Update BES with HPCP in the EMS document. - The Information modeling discussion (matching) should be added to the document. - Consult the Information Services Design Team into the EMS picture and refine the UML diagrams. - The position held by CDDLM/ACS still need to remain, but only if there is something to replace it. - Decision: keep CDDLM/ACS as a placeholder. - Priority: 1) BES Update w/ HPCP. 2) Update RSS section 3) Files (data staging). 4) Tighten or revise up the Information Services. 5) Consider revising the CDDLM/ACS section depending on what else might be available. Issues: - There seems to be overlapping use case work between HPCP and EMS. - These and some for DMI and Reference Model could be added to the EMS use cases. - What to do about CDDLM? There was some work done at UoV that might fit in this space. - This is an extensible deployment framework and some examples around JSDL. - Deployment from a .zip file - Deployment descriptor defining required binaries and libraries, but not fixing location. - CDDML would be another. - This might be presented to the community - This has no (current) relationship to the GLUE-2 work. - Possibly present to the GLUE group. - This also overlaps a bit with ACS, but this is recognized. - The next step could be passing it to HPCP for their next steps. - This could be published as an Experimental Document. - Use is made of RNS and ByteIO. - There was discussion about how this spec needed to be fixed. - Mark presented an overview of the idea. - CDDLM is a recommendation and they are working on it, but adoption looks questionable. - The scenarios are reaching completion and therefore we may be reaching the point where an Architecture Document could start. - RSS needs more manpower. Draft 5, has just been posted which may have addressed most of the problem issues. - Major problems postponed to later versions - implementation and adoption issues still pending. - It is ready for feedback and early implementation. Steve's Mail ========= Where should we go next with EMS Architecture Scenarios? The original document (http://www.ogf.org/documents/GFD.106.pdf) considered scenarios relating to job execution at a known endpoint, an endpoint selected through RSS type mechanisms, and execution requiring post/pre deployment steps. Open Issues (as I see them!): 1. Progress on defining EPS (as part of RSS) has been slow and AFAIK there has not been much progress towards its submission into the document process. There is however a draft from April of the specification and from June of WSDL/XSD files - http://forge.gridforum.org/sf/go/projects.ogsa-rss-wg/docman.root.current_drafts. This may not matter as work has progressed on the content of RSS -- namely the information model and the activity in the GLUE-WG. 2. Review of GLUE information model. The BES specification defined some minimal requirements we should ensure that these have been taken on board by the GLUE-WG team -- see http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/HomePage . Do we need more concrete scenarios from EMS to drive thisc or are the GLUE scenarios sufficiently comprehensive? 3. Files (or more generally data?). The scenarios say nothing about file movement. The DMI-WG has progressed since then and has generated some scenarios that could for into a revision of this document. The latest draft (http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-dmi-wg/docman.root.drafts) and the some use cases (http://forge.gridforum.org/sf/go/doc14666?nav=1 and http://www.ogf.org/OGF19/materials/505/Including%20Data%20in%20Simple%20Job%20Execution%20Scenarios%20v0%204.doc) are a starting point. Even some sequence diagrams (see https://forge.gridforum.org/sf/sfmain/do/downloadAttachment/projects.rm-wg/wiki/27thJuly2007?id=atch4476 and https://forge.gridforum.org/sf/sfmain/do/downloadAttachment/projects.rm-wg/wiki/27thJuly2007?id=atch4477) from RM/GLUE discussions that should be reviewed for diffs against the current scenarios. 4. Deployment and Provisioning. Are ACS and CDDLM dead? Should we refactor around work in the Reference Model WG and experience on lightweight deployment experience from UVa and GenesisII (BTW - Ifm sure there are other groups who could contribute here). Generally, having scenarios in the current version of the document using specs that are not developing and/or not going to be adopted is a concern to me. There is IMHO a clear benefit in having these sequence diagrams to inform other groups & incorporate their thinking into a single cohesive document. This should be one of our principals for future versions -- not to expand into a massive sequence diagram repository but to keep a narrow focus on incremental scenarios in the EMS space. This would be a useful reference for many groups and help to show how the work going on in individual WGs fits together. Steven PS -- Many thanks to the those whofs documents, emails and thoughts have been collected here!