OGSA Interim Meeting --- 11-12 May 2004 ======================================= * Participants Jeffrin J Von Reich (HP) Jay Unger (IBM) Jem Treadwell (HP) Ravi Subramaniam (Intel) Latha Srinivasan (HP) Dave Snelling (Fujitsu) Andreas Savva (Fujitsu) Takuya Mori (NEC) Dave Martin (IBM) Fred Maciel (Hitachi) Takashi Kojo (NEC) Hiro Kishimoto (Fujitsu) Andrew Grimshaw (UVa) Jeff Frey (IBM) Ian Foster (ANL) Abdeslem Djaoui (RL) Dave Berry (NeSC) Minutes: Andreas Savva Glossary: Jem Treadwell * Last teleconf minutes approval: postponed to next call. * Agenda bashing - Need more time to generate text than reviewing - Also a (perhaps) longer cross review section - Broader question of whether we think we are ready for final draft and how to go about it. - Decided on second agenda bashing tomorrow morning - Decided to split into teams in the afternoon - Possible connection/overlap with DMTF Utility Computing WG - Working on taxonomy that is a bit different than us - No Utility Computing F2F at GGF11 but many of the group's members are coming to GGF - Jeffrin would like to have some time there to discuss relationship. - Hiro to allocate one of the design team sessions at GGF11 for this. * OGSA diagram (marketing) - Background to creation - Need one slide to present to sponsors etc (marketing); for use by GMAC etc - Make no technical points wrt design; does not have to be the same as the 'real' taxonomy in the doc. - Identity (the image when thinking of OGSA) - This is a 'what' chart - We also need a 'why' chart and so on. - Comments on formatting - Text should not go outside the circles - (similarity with GGF logo?) - Services in big circles and the other circles are capabilities of those services (and remove 'service' word from the little circles) - Comments on content - Not Status & Monitoring -> Information and Monitoring - Information Services -> Discovery - Add Status or Monitoring (small circle) - Missing things - Availability or Autonomic category is not in the picture - Autonomic is everywhere; no need to have a specific entry (circle) - Availability (management): Appears also as a facet or aspect in other components. But it is one of the things people typically expect to see. - Include it as a separate category - Data replication - Do we think this picture stays fixed forever? - No, it will change over time and we'll have to update it. * OGSA document structure review - Information or recommendation? - Lacks the detail of a recommendation - Guideline to people writing specifications (so in that sense it seems to fall into recommendation) - Problem: How to come up with 2 implementations to actually move it through the recommendation process; tricky - Also it depends on specifications not yet standard - GGF Information track explanation mentions 'architecture' - Concern with Information track and lack of rigorous process to its acceptance (in comparison with recommendation) - Agreed to - Information track for first submission (if we can get it done for GGF11) - Recommendation track for final submission (at a later stage) - (Somewhat unconventional approach but possible.) - Need to publish something solid for GGF11. Possibilities: 1. Good draft identifying areas that might change (possibly deleting stuff that is not ready) 2. An 'outline' (high level architectural document) together with other documents that go in more detail (produced later on). 3. A somewhat extended version of requirements and use case analysis, and capabilities (as initial submission) 4. A higher-level unified draft covering some key capabilities or themes, e.g., PE, VO. And pointing out areas that need more work. - What our consumers want vs what we want (for GGF11) - section 5 (a factoring of services) 1. Single paragraph for each service 2. Do just a couple in detail - And the relation of GGF11 draft and the longer term specification - Produce a strawman of what we have (incl. revised chapter 4) and rethink. - Identify architecture principles (andrew to do a draft) >Done - Consider how to fit it in the document. ( - What are the expectations we have to satisfy by releasing a document and how long do we have to put it together. - Timeliness to influence other groups (incl. companies) - and/versus having something solid enough that will be useful ) - If part of ogsa mission is to coordinate other WG work we have to spend more time working with other groups. - In particular work in chapter 5 is not always directly connected to other WGs. Use stuff in chapter 5 as input/proposal to related WGs (together with overall framework) and use their output as final content of ch5. - Often such WGs do not exist - And do we have the overall framework set up already? (For scoping etc) * Document (chapter 4) review - OGSA Capabilities - Execution Services - Andrew: Ravi, Jeffrin, Jay, Chris, Andreas - Data Services - DaveB: Andrew, Dave, (Andreas) - Resource Management Services - Fred: Latha, Jay, Kojo - Security Services - skip; only one security expert attending - ?Self-Management? Services - Jeff, Jeffrin, Andreas, Hiro, Jay - (service level attainment) - ?Information? Services - Abdeslem, Hiro - Context Services - ? - Infrastructure Services - Ian (-For feedback to marketing picture too) - Service level attainment - Different level than chapter 4 or not (cross cutting) - contained in ?Self-Management? - ?Analytic? services - Not sure where this fits (possibly contained somewhere else) - Leave out for now * Requirements review - Read and comment session. - General agreement that this rewrite is an improvement on the previous text. - Detailed comments by person (with apologies for any incorrect attributions) Should also cover: - Network services - High level services - Service Composition - Policy Management Requirements for - protocols and schemas - resource description and job description - naming - access control - Check point & Migration Also - Move "resource utilization" section after "job" - Better separate out "QoS assurance" - Need reqs for "service level attainment" Requirements for - Intrusion detection Also - scalable computing section is too e-Science based, add commercial considerations - discovery vs query: difference is not clear - Usage of *must* may have to be toned down (and/or be made clearer that these are OGSA requirements not Grid ones) - Data catalog shouldn't be just data (naming) - VO refinement is needed (and relation with other requirements; seems at different level.) - It looks more like a solution of other requirements - (Site) autonomy and whether it can/should be delegated - (and level of requirement) - Extensibility - Ease of Use (Andrew also sent a more extensive list of comments to the list.) - Business utility model requirements - Lifecycle of HE; why is this different enough to be called out. - Requirements on composition, workflow (only description) - Need requirement for - monitoring - minimizing delegation - VO mgmt - Mixture between functionality and requirements (projected view) - Discovery vs query: not clear what is different - Security: minimize risk of misuse rather than misuse - Use case references; how meaningful are they. Consider removing completely. - Separate QoS into separate topic; not just as part of Job/Data - Firewall (traversal) is too specific; talk about 'organizational boundaries' or 'domains' - Problem determination in 2.7 seems misplaced - Meta-scheduling; what it means, it is not only for eScience - "dynamic" aspect - Performance aspects - is this a Complete list? And is this the right factoring? - "Job" section needs more refinement - Enable applications to support heterogeneity - Robustness of VO - Separate "functions" and "management functions" - Let application user drive grid system - Draw the line between "QoS (provided by resources)" and "SLA" - Most of them are functional requirements, we also need non-functional requirements - Need infrastructure requirements - Since 2.7 "resource management" is more important, move it ahead - Add "protection" requirement to security section. - 2.8 & 2.9 covers SLA, let's contrast them to supply side QoS. - More emphasis on adaptivity and dynamicity * <> * Agenda Bashing ** Sub-team reports - OGSA Capabilities - Execution Services Has 'detailed' text; agreed refactoring/simplification outline, to make up to (or rather down to) 3-5 pages abstract (meta) figure not just "run job" but more general use case - Data Services No text yet. Produced Outline. Expect to make 3-5+ pages Models Functional capabilities Properties Requirements on rest of OGSA - Resource Management Services - Text available - Working through some issues - Have a set of requirements to add to chapter 2 (Action: Fred to send requirements to Andreas/Hiro) (- Requirements on resources vs requirements on the managers of the resources - Need more work to define higher services (PE, Data, etc) to get a clearer image of what's needed further down (resources) - Connection to WSDM and what is needed to fit in OGSA (gap) ) - Security Services - Skip - ?Self-Management? Services - (Service level attainment, provisioning, etc) - Some high level text - To fold together with other text on SLAL and Provisioning - Call planned for May 13. - ?Information? Services - Working out outline/text - Need definition of event, information, etc other terminology - Cover a number of 'use cases': logging, broker, discovery/registry ... - Context Services - Skip - Infrastructure Services - Ian's text is on infrastructure assumptions - Andrew produced a list but it needs review/discussion ( - Discussion on the necessity of an "Abstract resource model" - For what purpose (universal vs used for 'mapping') - Do we do it vs define requirements and ask someone to do it for us - Jay to do a draft covering the following points - Need for model - GGF11 to GGF12 do requirements - Research on who is best to do it - Publicize by GGF12 - Make decision at/post GGF12. ) * Discussion on description pattern for capability chapter (Ch.4) - Proposal to use the data section outline for other sections Models Functional capabilities Properties Requirements on rest of OGSA - Models may not be applicable to other capabilities in the same way - Proposal to use 'PE' meta-diagram (Demand - Supply) as an organizational pattern (for other capabilities) - (Some concern whether it will create/raise more problems than it will solve and whether it can be applied to all other capabilities) - Decided to use it as meta-pattern - Agreed on a revised outline proposal (by DaveB) - Objectives - Models - Example scenarios - Supply/demand meta pattern - Functional capabilities - Interactions between capabilities - Properties - E.g. QoS - Interactions with the rest of OGSA * Glossary ** Grid service - Do we have to avoid the term just because it stirred controversy in the past? - No, if it is really meaningful (and is worth fighting for) - Yes, if it is just ends putting artificial barriers between grid and web services. - Is it possible to define its properties - Maybe (initially somewhat informally) - Andrew's list as one possible starting point - Some possible definitions (not normative) in Jem's summary. - Tend towards "a Web service ... designed to operate ... and meet Grid requirements..." - For the glossary - Agreed to add that OGSI GS term is deprecated - And informal definition along the lines above. * GGF11 - Informational document for this submission - Put something together by Friday and update later - Put in new requirements chapter (revised if possible) - Put marketing diagram at a convenient place (head of chapter 4?) - Whether to put Ravi's cylinder & relationships diagram or not - Would like to extend to show 'ogsa strata' more - (formatting (coloring) issue?) - Maybe add for this version (does it fit with what the text will be) - Action: Jeffrin to collect similar pictures and drive towards a common taxonomy (post ggf11) (Ravi, +) > Send your taxonomies to Jeffrin. - New structure for Chapter 4 - Chapter 5 removed for this version (future definition) * Document deadlines - Chapter 4 submissions - Most text to be available next week (early to late) - By Topic: - Execution by Monday - Data by Monday - Self-management by late next week, or next next Monday - Resource management by monday - Information late next week * GGF11 sessions - Reorganization of the existing sessions and adding one more session (self-*, information, context) Action: Hiro to send out the revised table. - Panel discussion: - Not clear what we are after with this panel - DaveS: it is part of OGSA-WG's contribution/service to GGF (GFSG). Advertising of the flagship architecture. - Jay's idea: Call on an Analyst (e.g. IDC, Gartner) as moderator and three OGSA-WG members as panelists. After each panelist advocates his opinion (10 min each), moderator ask a couple of questions and panelist field them (about 30 min) then pick questions from the audience. - Jeffrin propose "Grid and Utility computing, same or different?" as its title. - Agreed to keep current title as is and refine expected content later. * Identify architecture principles - Reviewed draft by Andrew - One slide from Jeffrin (separation of management concerns, multiple model support, etc) - Andrew to update draft and then decide where to add a section in the document "Design Principles" - Make sure only 'non-obvious' things are included