OGSA Teleconference - 1 February 2006 ===================================== * Participants Mike Behrens (R2AD) Hiro Kishimoto (FJ) Allen Luniewski (IBM) Fred Maciel (Hitachi) Steve McGough (IC) Dejan Milojicic (HP) Takuya Mori (NEC) Andreas Savva (FJ) Chuck Spitz (CA) Jun Tatemura (NEC) Jem Treadwell (HP) Minutes: Andreas Savva * Summary of Actions Action: Andreas will check Greg's email again and followup with Hiro. Action: - Dejan(CDDLM) to provide a CDL for deploying and configuring BLAST - Steve/Andreas(JSDL) to provide a JSDL document for submitting a BLAST job Action: GGF16 panel followup (see detailed list below) * January F2F (01/19) ByteIO minutes approved with no changes * January 25 minutes approved with no changes * January 30 minutes approved with no changes * Basic security profile - Core and Secure channel - Takuya has issued a final call on the list. - Review and comment by next Monday ** "Status of memo" question to Greg No problem with changing the text, but it is not clear if the title could be changed also. Action: Andreas will check Greg's email again and followup with Hiro. ** WSRF BP 1.0 status - WSRF is entering the process towards becoming an OASIS standard - Tom proposed that the WSRF BP should be re-submitted once the WSRF specs become OASIS standards. - There is another document in the GGF pipeline (ByteIO spec) that uses the WSRF BP normatively. The desire is to publish the WSRF BP some time in advance of the end of the public comment of dependent documents. - Hiro proposed waiting until GGF16 or end of February before re-submission but not longer. (No decisions made.) ** RSM License: no update ** CDDLM discussion Jun sent out slides on CDL before the call and the group reviewed them. ** (2) Example 1: Application Server - 'Component provider' defines the components - And in this case also provides the instance of the component (component in the 'running' state) - 'Component user' in this case might also take on the role of a system provider. In other words, the 'component user' may be composing the system for himself or to provide a service to other users - There are some issues with terminology (but perhaps it is unavoidable). - Boundaries here are the components and the roles relative to components ** (3) Component description - CDL does not define how to relate configuration and resource parameters - There is also no requirement that such information be present. The interaction or combination is not defined and is probably an open issue that should be addressed by this group. - Some such information may be present as properties for reference purposes - The semantics of configurable parameters are not defined. It is possible to include semantic description in a separate document or as annotations, etc. - Since this level of description is still too abstract, it was proposed to show a concrete example of JSDL and CDL and how the two relate to each other. - Dejan also suggested doing an implementation fest: - Bring together people developing various components and do a 'reality check' by trying to combine the various components of the EMS architecture. (Different from an interoperability test which brings together people developing the same component.) - And do it as a regular event, e.g., at each GGF. - It was pointed out that the purpose of the 'EMS Scenarios' document is to drill down to that level. Doing a real example, e.g., BLAST, for CDL and JSDL could be useful as a next step. - Agreed to work through such an example at the next GGF. Action: - Dejan(CDDLM) to provide a CDL for deploying and configuring BLAST - Steve/Andreas(JSDL) to provide a JSDL document for submitting a BLAST job ** (4) System composition - Text in red are the results of a refinement of the CDL document - The deployment API expects that all the values in a CDL are instantiated by the time the CDL is submitted. There is no statement on how that refinement is done. ** (5) System template The document on the left is a user 'template' (in contrast, in this presentation component provider templates are yellow). This template is an intermediate description of the system and further refinement is shown on the right side. ** (6)-(8) - There was confusion on the objective of this second example, some of it stemming from the introduction of the term 'job'. The example may be seen as setting up a cluster with a DRM. - It is a more complex example, and it was agreed to concentrate first on the simple case described earlier. ** (9) Further Examples - Clarified that the server/machine/linux boxes essentially represent the same things in the slide. * OGSA(tm) EMS Architecture Scenarios - No objections to the proposal to change the name of the document. - Question about meaning of 'policy' appearing in some of the sequence diagrams (Section 2.5 and some of the Appendices). - 'Policy' is a placeholder for now. - The document is still changing and contains internal inconsistencies. * GGF16 Planning ** Panel: Monday 1:30 - 3:00 Discussed possible candidates for the panel: - JSDL: Steve or one of the other JSDL-WG chairs (ok) - EGEE: Steve will make initial contact with people in EGEE (and cc Hiro) - DAIS: Hiro to ask Malcom - Other possible candidates: - Hiro to ask someone from NAREGI (Japan), Globus (Ian) - Steven Newhouse (OMII) - Vendors: who? - Panel Moderator: Hiro to consult Dave S on candidates. - The panel should be at most 5 people, excluding the moderator. - Send proposal to Hiro on how to publicize the panel ** Information model session - Use the teleconf next Wednesday to prepare for the GGF session. ** GGF16 F2F meeting Agenda proposals: - CDDLM and EMS joint session - Other EMS scenarios (including RSS-WG etc) - Information Model - General session - In particular finalize dates/locations for April F2F and GGF17 F2F meeting * GGF17 F2F - Hiro has speculatively reserved a room both Monday and Saturday at the NAREGI office. * April F2F - April 3-7 seems to be the more popular choice at this moment - SF or London are equally popular