OGSA Teleconference 26 May 2004 =============================== * Participants Sachiko Wada (Ascade) Jeffrin Von Reich (HP) Ravi Subramaniam (Intel) Latha Srinivasan (HP) Dave Snelling (Fujitsu) Frank Siebenlist (ANL) Andreas Savva (Fujitsu) Fred Maciel (Hitachi) Bill Horn (IBM) Hiro Kishimoto (Fujitsu) Dave Berry (NeSC) Minutes: Andreas Savva * Early Discussion ** Minutes May 19 - approved with no comments ** Data section update - The Data design team had a short call. - Text basically ok; will carry out minor changes and add to the OGSA document. - Probably no more design team calls until after GGF11 ** OGSA Secretary position - Ian proposed Andreas as OGSA secretary - Andreas confirmed that he accepts the position if there is no disagreement. - Dave (S) noted that both Area directors voted in favor. In addition - The Secretary position is not an elected position. It is typically assigned at WG creation time. - Changes are done via the typical GGF process (consensus) - In contrast to Chair changes it probably does not require GFSG approval. - Consensus to accept the change. Wait for any objections on the list and finalize at the next call during minutes approval. * GGF11 ** Document status review - Hiro uploaded an updated review schedule to gridforge https://forge.gridforum.org/projects/ogsa-wg/document/ogsa_doc_review_schedule/en/3 - There is text (at different level of maturity) for almost everything except Context and Security capabilities. - Context - Considered deleting it but agreed to leave it in as placeholder (so as not forget it) - Security - Frank will provide text by May 28 and the group will review it during the next call (June 2) [Note: May 31 is a holiday in some countries (US and UK)] - Plan to GGF11: - Send text by end of Friday (5/28) or contact Andreas if you cannot do so. - Andreas will put the document together - Email review on the list and final review on June 2 teleconference. Action: Andreas to create an input folder and/or speed up merging process to ease review. >Done Action: Andreas to send Frank a copy of the Data section and a fragment from the minutes to guide him in creating the Security section. >Done Action: Ravi to send the diagrams with text for inclusion at the head of section 3. >Done - (And consider their relation with OGSA marketing picture) ** GGF11 session plan - Panel session - Title: Exploring opportunities in OGSA service model - Structure: Moderator and 5 panelists - Message: How OGSA can be used to solve users' problems - Assuming OGSA exists in its 'current' form, what benefit do users have. (Without going into OGSA individual service details.) E.g., What kind of improved services can a service provider support by using OGSA (service provider: providing the 'layer' between OGSA and user). - Moderator: Jeff Nick (not confirmed yet; might change) - Panelists: - Jeffrin Von Reich (Utility computing service provider) - Jeffrin was planning to talk about how utility and grid are related and that people should be looking to OGSA as a utility computing platform. But will change the message slightly to "OGSA is the right way to do utility computing" - Malcom Atkinson (Data) - Ravi Subramaniam (EMS) - Toshiyuki Nakata (Grid Data Center) (not confirmed yet) - Kate Keahey (Collaborative research) - If you have any ideas for further panel refinement contact Hiro or Dave. - Panelist should prepare 5-6 slides for initial position statements. Action: Dave to send proposal to list (and to Stacey after confirming with all participants) * Self-management review - Jeffrin sent the document to the list before the call: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/05/msg00090.html - Review by section - Objectives - Automate all procedures etc. - Service level manager concept - Difference between service level manager and policy manager - Service level manager is focused on optimizing objective - Policy manager focused on policy distribution and management - 'Protecting' is mentioned but no explanation - Some text in 1.1.3, second bullet - Proposal to rename self-management to auto-management - The argument being that "self-" implies singleton; "auto-" implies automation of a set of services - Followed by a discussion on whether "auto-" suggests the idea of managing oneself, and whether "self-" implies autonomous management. - "Autonomous" suggested as compromise ('autonomic' is taken) - The name change proposal was rejected. The consensus being that "Self-" is more acceptable. [Minute taker's note: The Greek root "Auto-" is equivalent to "Self-"] - The text in this section seems to imply that every service in the architecture has to have the "self-" properties; not right. - Need more wordsmithing to bring out the autonomous nature of the system (but not necessarily for each individual service) - 2nd paragraph: "specified service" should be "set of services" - Models - Discussion on whether to rename to "Basic concepts" or not. "Models" does not quite fit. - It is not essential to keep the exact same structure for each capability. - Agreed to delete Models and move up "Basic Attributes" instead. - Also promote "Example Scenarios" - Service and Resource Model - Andreas proposed that this should be something along the lines of "Knowledge relating to service/resource" instead. And the Service/Resource Model text should be moved to "Interactions with OGSA." (It is what the "self-" services can do with the model rather than the model itself that is important here.) - Some concern that "Knowledge" is too general. - Agreed to change to service/resource manageability model (manageability services), move to "Interactions to OGSA" and make the text point to the Resource Management capability. - Consider adding text to draw out the aspect specific to self-management in this section. - Which layer uses self-management? Is it the top layer? - Each layer would manage itself (and form aggregations of self-managing components) - Service level manager - As a concept it is much broader than self-management; it will appear in other capabilities - Managing based on objective; any type of objective - Taxonomy issue also raised - Proposal to rename to Service Delivery Manager - Concerns raised about what the terminology change would do to the rest of the document, e.g., "service level attainment" and so on. - Agreement that the current terminology seems to have some problems but it is not completely flawed. Decided to keep it for now and come back to discuss later (during the design team meeting at GGF11 or after GGF11). - Another proposal was "QoS manager" - Including qualitative (and quantitative) measures - A lot of disagreement on the concepts; postpone discussion for later. - Agreed to move some explanation on the generic control loop into the earlier section on Service level manager model (for expository reasons) - Example scenarios - In Job level management, remove QoS and talk about SLO instead (QoS is misused in the text). - Agreed to add a Grid system scenario - Provisioning - Agreement that it is extremely important - But there is no consensus reached on its definition. And the tentative agreement within the design team is that it is not part of self-management but something used by self-management. - It is pointed to in "Interaction with OGSA" - Section 1.1.2 is fairly abstract - Deployment and configuration capabilities should be discussed more or at least mentioned (and point more concretely to work done by CDDLM). Add some text in the Capabilities section. - Service level management (1.1.2.1) - Monitoring: Point out that it is utilizing the monitoring capabilities of resource management - QoS (1.1.3.1) : Should be about QoS management - Entitlement (1.1.2.3) - How is it different from reservation? - It could be an earlier stage of creating a resource reservation (a looser concept of reservation). E.g., an "option to reserve" - Discussion on whether it should it be discussed here or whether it should be covered under EMS - Agreed to leave it here and revisit this issue again later. - Predictive analysis (1.1.2.6.2) - This should probably have a more general title ("Analytics") since it is not always necessary to predict. - Properties - Separate SLA and QoS concepts - Interactions with OGSA - Either add some text for each section or write this section as a couple of paragraphs. - Agreed for this version to write it as a couple of paragraphs. - Probably if cross-references are done right the contents of this section can be deduced semi-automatically.