OGSA Interim Meeting 12 - Resource Management ============================================= Location: Fujitsu Labs America, Sunnyvale, US Date: 17 August 2005 (Day 3), afternoon Attendees --------- Andrea Westerinen (Cisco) Tom Maguire (IBM) Hiro Kishimoto (Fujitsu) Andreas Savva (Fujitsu) Fred Brisard (CA) Takura Mori (NEC) Steven Newhouse (UoS) Michel Drescher (Fujitsu) Allen Luniewski (IBM) Soonwook Hwang (NAREGI) Ellen Stokes (IBM) Steve McGough (IC) Donal Fellows (UoM) Jay Unger (IBM) Fred Maciel (Hitachi) Andrew Grimshaw (UVa) Michael Behrens (R2AD, LLC) Pete Ziu (Northorp Grumman) Mark Morgan (UVa) Ravi Subramaniam (Intel) Phone Bridge: Jem Treadwell (HP) Minutes: Mark Morgan (Minor edits: Andreas Savva) Agenda ------ * Nomenclature * Scenario Discussion I * Scenario Discussion II Model Terminology ----------------- Presentation by Ellen Stokes (as per slides) https://forge.gridforum.org/projects/ogsa-wg/document/model-terminology/en/1 * It seems that an information model could define some sort of an enumeration without being rigorous about representation that still had the ability to put constraints around translations. * There is a fuzzy line between these distinctions * These are coming out of RFCs, so for the purpose of these discussions, they are what they are * Data models are really about the information and the binding. * What is a resource model -- is it a specialization of a information model or a data model. * Example of a distinction between a data model and an information model - From CIM environment * In brief: 'information model' is abstract; 'data model' is concrete (e.g, a binding of the information model) and 'resource model' should be deprecated as a term. - And OGSA should work on Information or Data Model * SNIA is doing a profile of both the information and the data model. * The only interoperable mechanism is WBEM, but going forward they may use SMASH or Web Services * Profile is -- if you are interested in asset management, then these are the X classes that you are interested in. * Oft used terms are Semantics and Renderings - Semantics of the model are of the information model - CIM is semantics and as such is an information model, WBEM is a rendering and as such is a data model. * Fred's documents predate the terminology described here * Two topics for discussion - What about the term resource model? - What are we trying to achieve by "this"? What is the goal of all of this? * Given the set of definitions described, with respect to the renderings, we are clearly talking about data models when we talk about ByteIO and BES. * What is the information model at the abstract level that we need to surface through these various places. * One role of this sort of activity is to describe an abstract model of each of the services -- if that is what we want to use something more, then that comes back to what we were saying on Monday about the objection to IDL * What is the common set of semantics around properties, etc. irrespective of protocol.... * Posit that each of the different disciplines (RSS, BES, ByteIO), have different loci of interests within the model. Those spheres of interests have overlap. We don't only want to understand how each is modeled, but also how they all fit together. * Is there more then one legitimate rendering? No, there can be many. * So, there is one rendering per profile. * Can we define new classes from CIM that selectively inherit from existing ones? - Yes * There are reservations about CIM. CIM is very precise, but Grid tends to be less so. CIM may not be the best model for what we are trying to do. * What are we trying to do here? - We could take BES (which is purely about operations), re-write the pseudo IDL code and re-code it as CIM op things. Now that we have that, can we apply a transform or rendering to those to produce the WSRF Basic Profile compliant version. Is that we are trying to do? -- No * The whole aspect of taking CIM and using that as an abstraction and then having a rendering of that...the question here is about the specific CIM thing. * What is the model that is there? How can we use the pieces of that? What needs to get driven back into CIM about what we have learned?* Not every operation in a discipline needs to be pushed back into or adopted from CIM. There may be operations in a discipline which take information from outside and push it inside. * People constantly look at this and they say "It's too big, it's too complicated, it's too specified.". But, we have the ability to define our own extensions. * The next big question that will impact RSS is, is it just CIM-OP, or CIM-DATA, etc. - Andrew thinks that just doing the CIM-OP isn't right. We have this wealth of model, let's use it. * Clarifications - There are two things that CIM provides -- Framework, a language to express these things * Many people in the academic community would consider the properties the Information model. * All of the extant info models can inform further interaction * Violent agreement to use the CIM framework, to use some CIM classes, and to provide feedback back into the DMTF about CIM. * Tom went further and said to use CIM style modelling as a mechanism in the GGF to produce Classes etc. relevant to our further... * There may be some operations that we may want to render in CIM, and then bring into WSDL, but there is probably lots that we don't want to bother with. * Seems important that we go back and look at the things that we have done, look at the operation interfaces that we have defined, and tease apart what is the operation and what is the information. Have that inform further discussions on framework, etc. * The distinction on the CIM profile (based on SNIA profile) is that you can take pieces of what's there and get rid of the other. In OGSA, profile extends something already there, but doesn't remove anything. * Is this something that goes forward in the RM design team, is there a new modelling design team that needs to be created... where does this go? * What is the question being posed? What group within OGSA comes up with the toolkit that the WG use....What is the form of the guidance? Scenario Discussion ------------------- * Information already available - The JSDL to CIM mapping exercise See: https://forge.gridforum.org/projects/ogsa-wg/document/Model_Proposal_PDF/en/1 * From a BES perspective - A BES Container will have attributes from Disk Space, CPU Arch, Network Bandwidth, OS, Filesystem...things from the "LogicalElement" - That is sort of what a container is. - Similarly, applications are something that will need to be more richly described. * What do the colors mean - red line is a relationship - green line is a type of aggregation - blue line is inheritance line. * You mean this is a subsetting of the same model. You choose some small number of classes to put in here, and a small number of properties and methods. * Red is a proposed class that the GGF would propose back to the DMTF. * When you say you have a filesystem, what do you mean? - Notion of a file system in the DMTF is like in NFS, or any kind of container for files that tells you how you access them. - Do you have the notion that a directory within a filesystem is a filesystem in and of itself -- Yes, you could do that if you mounted that directory on another system * Gut feel is that the advantage of CIM as opposed to GLUE is that CIM is being adopted by many parts of the corporate world. -- This seems irrelevant because you could take exactly the same GLUE structure, put it into the CIM model and you have the GLUE schema represented in CIM that gives you a great thing to go back to the GLUE schema folks and hey, we can actually do that using the CIM tools. * Steven to give GLUE schema presentation * Where does the information come from? - Logically from the resources themselves. * GLUE is a by value aggregation containment * There is no right or wrong model, but we need to consider that there is an alternative to CIM that is being used by some relevant communities here. * Management issue is a concern -- this is something else that we should address. What is the scope of the OGSA WG's adoption of CIM? If we are going to do management with it, well, then we get nervous. If you mean that the properties are going to be disseminated through some standard way, then fine, but management is a very broad term. If we say we are going to use this work to manage those services, then we need to be very explicit about what we mean. * The distinction between management and functional isn't important here. * Two main users of management facilities - Autonomic - Management Console * More important than defining what is management and what isn't is to go through the scenarios. * The JSDL document may have requirements and an application name. This may impose additional requirements. * Does the job need to go into the InfoServices? - Ravi says yes - Andrew and Ellen say no * Is there a simple service that we can walk through with an eye towards information services? * UML has sequence diagrams -- isn't that what we want to do here? * This is in the 1.0 diagram as text, not UML * Can we take the EMS work as a typical pattern and use that as the basis for instantiating either one of two scenarios? In other words, is the EMS pattern typical or an example? * We have a set of available services that we have a fairly clear idea amongst us what they do. * Let's split them up, and do UML sequence diagrams, creating operations for each available service. Come back and present them. We may find that we have a common set of operations that form the basis of what we need. We can then have a quick validation of the BES interface and might come up with a quick set of interfaces for Reservation, etc. * Are we going to go down this route tomorrow for an hour or not? * Is it the desire properties and functionality in an information model that we are going after with this? Or is the objective of this exercise to figure out which properties we want in the model. - Let's do the latter. Let's make the sequence diagrams and then figure out how to profile them. After that we can expand to the information in EMS. * Motion on the floor to break for an hour tomorrow to come up with sequence diagrams. Any disagreements -- No - Peter, Hiro, Tom to do UML tomorrow - Blast, Patching, Cache Service - 3 Tier Application - Consolidation Services - 1 hour to make UML - 1 hour to present and discuss - If this only takes two hours tomorrow, do we want to then go through the document that Fred made. - Information on practicalities of moving forward would be good. - Meaning, how can we express stuff that's going to be understandable by the CIM guys. -- UML is fine.