EMS teleconference minutes from Jan 17. Url: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-ems-20050117/e... (Sorry for the delay. I wasn't actually asked to take minutes but Hiro wouldn't let me off the hook.) -- Andreas Savva OGSA EMS Teleconference - 17 January 2005 ========================================= * Participants Ravi Subramaniam (Intel) Dave Snelling (Fujitsu) Andreas Savva (Fujitsu) Mark Morgan (UVa) Tom Maguire (IBM) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Andrew Grimshaw (UVa) Ian Foster (ANL) Dave Berry (UK NeSC) * General discussion - Agreed that the EMS space lacks concrete specs. - Initial focus on capabilities to guide effort in exploring the area---it seems premature to do an EM profile. - JSDL and WS-Agreement do seem to have some momentum behind them. But these pieces do not offer sufficient coverage to do a profile. - (Clarification that a Profile's purpose is interoperability.) - Proposal for discussing what a reasonable aim is---a gap analysis of sorts. - Agreed to the following: 1. Document the process of defining what we want to do a) Look at what there is in EMS (OGSA version 1.0) b) Subset it c) Union with outside specs d) Decide where new groups are needed (to fill the gaps) - Goal: short-term (candidate) profile that can produce something demonstrable - Clarification that "short term" means "year's end" - *Candidate* profile since it only has to identify the activity leading to a spec. - Detail concepts first? Might not finish until the profile is done. - Profile to cover as a minimum a "Hello world" level of functionality. 2. Look at what is there already in the EMS draft and what is the minimum subset that can be done as a first step. (To do.) 3. What is basic functionality? - Talk to a service/container/resource to start up something - If the executable is there just pass a path to it, or get it to the machine first---in some simple manner (no full-blown deployment configuration; just a data transfer) - (Ian) GT4 as an example that covers such simple functionality - (Dave) Unicore/unigrids as another example - Other efforts might offer input here, e.g., EGEE, etc - These examples might look very similar but their are subtle differences Proposal: Do a BoF on basic EM functionality. - The two projects above are willing to put forward complete WSDL specifications of relevant port types. This is important because they can be used as the starting point for standardization. - Should the entry point be the existence of WSDL specs? - Various opinions, but the rough consensus towards 'yes.' - Would like to also get Condor on-board (but need WSDL) - Condor has a WSDL sub-project: "Condor meets Soap" aka 'birdbath' - (DRMAA as an example that has an abstract definition but looks like a lot of work to put in WSDL) - Shared understanding that we can look at existing effors, invite groups to join, but cannot force participation in such a standards effort. And cannot just stop and wait. - Is there a preference to start from scratch? - Or, make sure that other efforts are also reviewed? - Consensus that it is easier to start from existing examples Action: Ian will send a pointer to the list describing the GRAM interfaces (Done) - Agreed that background work to review the various material is needed first. - For BoF need to also leave door open for people who may be proposing solutions not based on WSRF (e.g., OMII, etc) - The BoF is in addition to the profile work; fill the perceived gap in the EM space while the profile defines interoperability. - Clarified that the BoF is specifically on the submission interface; not the whole EMS space. - JSDL and WS-Agreement might be pieces used in the Profile. - (And might need more bofs for other pieces as gaps become more visible) - Forming such a group motivated/became obvious due to the work in EMS - Need/desire to make sure that it fits in OGSA-EMS - And that can only be done through participating in the proposed new group. Action: Work on drafting the charter for the BoF - Obviously do not to call it EMS; it is focused on a small subset: 'submission API' - This is not technical (design) work. - If the process is - (simple definition/provisioning), instantiation, execution, management - then BoF preparation is to decide what the minimal subset is. - Andrew and Dave volunteered to do a draft (initial proposal) of what is the important basic functionality and scope it as part of F preparation (initial proposal) (partly done) Additional actions: Action: Dave B to send WS-Agreement and DAIS link to the list. Action: Ravi volunteered to do a map of existing specs; what is there, now * Next EMS call: Jan 26 (to include BoF discussion) * OGSA EMS version 1.0 revision update - Andreas did a revision of the EMS section in OGSA version 1.0, to address some lingering issues: removing the term 'task' and modifying the explanation for 'Job' - Key changes: - Replace 'task' with generic 'unit of work' or delete as appropriate - Change order in definition of 'Job' so that the statement 'Job is a resource' comes later. Also remove too concrete statements (job is not workflow) that raised many comments at GGF12. Action: Andreas will fold in changes to next (final) draft and review in a subsequent call. (Done)