OGSA Interim Meeting #14 - 4 April 2006 - Day 1 =============================================== * Participants Hiro Kishimoto (Fujitsu) Andreas Savva (Fujitsu) Fred Maciel (Hitachi) Michel Drescher (Fujitsu) Allen Luniewski (IBM) Steven Newhouse (OMII) Duane Merrill (UVa) Mark Morgan (UVa) Jay Unger (IBM) Bridge: Chris Jordan (SDSC) (am) Dave Berry (NESC) (pm) Minutes: Andreas Savva * Agenda Bashing - Discussed whether to schedule a discussion for the ESI draft sent to the OGSA and OGSA-BES mailing lists at the next day's EMS session. Since the ESI draft was just sent out there is no time to review it beforehand. It was agreed to postpone the decision for tomorrow. - Agreed to have a short discussion on the WSRF/WS-MAN convergence document this day. - The Security area is a source of concern, due to the lack of progress. This should be one of the issues to discuss during the security session and what can be done to improve things. * Document status review Reviewed the status of the OGSA deliverables. ** OGSA WSRF BP 1.0 - Some minor updates are needed to bring it up to date with the WSRF 1.2 OASIS Standard version. - Tom will make the revisions. ** EMS Architecture document Pointed out that this is a separate document from the EMS Architecture scenarios currently in draft form. Discussed what form this document might take, drawing an analogy with the Data Architecture document developed within the OGSA-Data WG. Agreed to postpone the EMS Architecture document since there are too many uncertainties at the moment. Instead publish the OGSA EMS Scenarios document up to the scenarios covering the CDDLM interactions instead. The focus should be on using existing and formally published (or in public comment) specifications. Milestones: First draft by May 2006, for PC by July ** Information Model documents Two documents (guidelines and modeling) are expected to be complete or nearly complete by GGF17. * GGF17 planning (See Hiro's slides for the updated slides.) Two sessions planned: EMS and Information Model session 1. EMS: Introduction and explanation of scenarios 2. Information Model: - Guideline and model explanation - Interaction with GIN and their work (GLUE sub-set?) Action: Steven Newhouse to ask Jennifer Schopf on the status of the GIN modeling document. * Teleconference schedule - Agreed to move Wednesday teleconference to Thursday and change time to 1:30 GMT. - Discussed how to improve efficiency of the meetings: Some proposals: - Shorter, single topic meetings - Agendas sent out well in advance (at least 48 hours). [This is already common practice.] - Upload/send out material in advance. At least 24 hours in advance (some suggested 1 business day instead) so as to avoid last minute cancellations. And the co-chairs may choose to cancel meetings if no relevant documents are available. - (Semi)automate the above using gridforge. - No firm decisions but will try out the various proposals especially the rule on uploading material well in advance and cancelling meetings otherwise. - Reviewed the proposed schedule. Hiro will send this out to the list. * WS-Management Roadmap discussion Agreed that convergence in this area is a good development. But there are many concerns with the proposed way of going about it---outside the standards process until almost the end. We must make clear that the proposed process is not acceptable and that the specifications must be brought to, and developed in, a standards body quickly. Also discussed the functional equivalence of today's specs and the future 'converged' specs. Agreed that this is a topic that should be revisited when the relevant drafts are made available. Action: Hiro to schedule a discussion in the OGSA F2F after the converged specs drafts are released to discuss which sets of specs to use within OGSA. * OGSA DMIS WG (proposed) discussion Michel gave an introduction to the proposed DMIS WG (See also slides on gridforge.) - This is a proposed OGSA-prefixed WG. - There was a BoF at the last GGF - The official proposal (7 questions) were sent to the Area Director. - Will it used WS-Agreement? It is a candidate but there are no decisions yet. - Two renderings: WS-I and OGSA WSRF BP. And will probably factor or at least identify a core component that is not specific to either of these renderings. - Is it just for files? No, it should be more general (data oriented) than file oriented. - Scope contains both the setup and the transfer functions. One approach might be for the setup portion (agreement portion) to be done in another WG. - ByteIO relationship? ByteIO is more for remote access. It could be used as the protocol for transfering data. - Is it copying or moving (including ownership so that there is no copy remaining at the source)? It is copying. But could implement other semantics in addition. - The way names are defined is an important component. WS-Naming is a candidate here. There are some concerns on when that specification will be available however. - What happens if the data to be moved is produced on demand and does not have a name? Can you give as an input the producer of the data (the data factory)? DMIS specifies the management of the operation not the definition of source and target. * Information model review ** JSDL 1.0 to CIM 2.10 mapping Reviewed Excel sheet by Ellen Stokes. - Potential additions to CIM are marked with text "(new)" - Type description not completely checked yet - CIM does not have an equivalent to the JSDL resource requirements. A new class is needed. Some of the contained attributes will then come from existing CIM classes. - In the excel sheet 1/3 is CIM re-use and 2/3 extensions. Ellen made a choice to mark as "new" certain JSDL attributes (e.g., individualPhysicalMemory) that may have CIM equivalents in some classes but may not match exactly in semantics. - (Does CIM cover time varying values? E.g., the available memory may change over time.) - There is a bigger issue with the matching between the JSDL description and the advertising of resource capabilities. There are two options: building the description of the capabilities on top of CIM (CIM informs the capabilities advertised but those capabilities may not be based on the CIM metamodel), or in CIM. In many cases what might be advertised as a capability may be some value that is calculated using a combination of underlying CIM attributes and may be different depending on who is receiving it, due to different policies applied for different users. - Proposal is to come up with a way to create that abstracted/simplified/derived view from the more complex underlying CIM description. (And this abstracted view could still be defined as a CIM metamodel together with algorithms to map from the complex view to the abstracted view) - Matching would be done against this abstracted view - RSS would use this abstracted view for matching using the job requirement description. (- It may also be possible to use this underlying approach to defining the model for expressing these capabilities for defining resource requirements in a future JSDL specification, with the requirement that such a future spec would also allow transforming existing 1.0 documents to the new spec.) - The information available in CIM now is geared towards management while the abstracted information would be geared towards workload management. Proposal: Do a position paper on how to model this capability space and how it is derived from the underlying CIM model. Action: Ellen will do a revised visio diagram that has only the relevant BES attributes and JSDL attributes (base it off the info_model_for_BES/BES Container class) * Modeling guidelines document review - The term 'Profile' gives the wrong impression since the previous discussion implies that this is not a restriction of CIM. Agreed that it would be better to call it 'information model specification'. - Who does the rendering? State that it is the individual WGs. - In section 4.1 to aid readability, adopt the same style of definitions for status as described in GFD.59. For example: 4.1.x Recommended OGSA IMP as Proposed Recommendation Every CIM class in a Recommended IMP, when at the Proposed Recommendation stage of publication, MUST have one of the following DMTF CIM class status Final or Experimental. Every CIM class in a OGSA IMP Profile, when at the Proposed Recommendation stage of publication, MUST be Interoperable. CIM classes referenced by a Recommended OGSA IMP MUST be use the same version of CIM schema. - Add DMTF CR process as new section in chapter 4 - Merge section 4.2 into section 3.2 - Merge chapter 5 into section 1.1