OGSA teleconference - 19 July 2004 ================================== * Participants Andrew Grimshaw (UVa) Bill Horn (IBM) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Tom Maguire (IBM) Andreas Savva (Fujitsu) Latha Srinivasan (HP) Andrea Westerinen (Cisco) * CIM Tutorial (part 2): Early discussion - CIM Profiles - Hiro expected CIM Profiles would be simple and short and present a more consice view of the CIM model but actually they are quite long and seem very complex. - Profiles are not the place to start to understand CIM. - Review material using the preliminary version of CIM model 2.8 * Core specification review ** p1 Overview of CIM model - Shows all the concepts that are in the model - ManagedElement is the basic component - LogicalIdentity an attempt to avoid multiple inheritance - SettingData & StatisticalData are new. The older StatisticalInformation and Setting to be removed in 3.0 - Component and Relationship: could not change from abstract to concrete without breaking other stuff - Created versions of Component and Relationship that can be instantiated (superclass is abstract but can instantiate specific 'x') ** p2 Managed System Elements - Job is a LogicalElement (abstract class) - Concrete subclass has specific information about running job - E.g., Request state change of job - (And KillJob in abstract class is deprecated in favor of this.) - A way to monitor/manage a job - The Job class should be a superclass of anything that is a job - Since it has operations CIM is not just a data model. It also provides an operational model. (Can be thought of as an object model.) ** p3 Enabled Logical Elements - Not all LogicalElements (LEs) are EnabledLogicalElement - Meaning of Quiesce? 'Finish current work but do not accept more' - It doesn't necessarily mean 'sleep'---it is implementation specific - How are LEs named? - Instance ID in Cim 2.x - Key in 3.x ? - Rules to create unique names - Are these URNs? - Vendors qualified prefix plus other value - These will probably end up being URNs - Is it part of the model how to resolve them? - That is more towards implementation. The model makes no assumptions - Also another open question is how to do semantic equivalence - All boxes defined normatively in MOFs and also discussed in white papers - AccessPoint: way to get hold of a service - RemoteSAP: e.g., a phone number. - System: an entity viewed as a whole but made up of many parts. ** p4 Physical Elements and Logical Devices - (Red text marks deprecated features; will be changed in CIM 3) - If a feature is deprecated MOF provides information on what deprecated for - PhysicalElement location existed. It was moved to the superclass of Element location to allow more general 'use' - LogicalDevice is a representation of PhysicalDevice ** p5 Collections - Collections can be multisets ** p6 Redundancy Group - It can represent any kind of redundancy information - It will be changed and improved in v2.9 expected at the end of this month - It can represent both a spare and extra capacity group ** p7 Product, FRU & Software Identity - FRU is deprecated: there are 3 different concepts: what repair person brings, what can be FRU, and ... - This will be cleaned up in v2.9 - SoftwareIdentity should have been called SoftwareApplication but the name was already taken. It is expected to be cleaned in v3.x - ServiceRelationship off Product indicates where the product was bought from. ** p8 Statistics - Separate what is unchanging data (capabilities) from the information that may be rapidly changing and which might require monitoring - Statistics can be logged (message log concepts) - StatisticalData is raw data. It can be processed as time series etc. ** p9 SettingData, Profiles, Capabilities, Poer - p9 onwards are or will be deprecated and removed ** Other discussion - MOF is like IDL - Can it describe semantics? - It describes what the method is trying to accomplish in addition to its signature. It gives a complete description while UML provides an overview - Definition of semantics often ends up being prose - Qualifiers include more formal information for doublechecking as well - (Cisco uses schema regex as qualifiers e.g., ipv4, ipv6 address is X) * System specification review ** p1 UML ** p2 ComputerSystem - Deprecated PowerManagement - Cluster is also deprecated in 2.9 and reworked as a RedundancySet - ComputerSystem remains but many of its subclasses are deprecated - Dedicated: what it does, if it does only one thing. - As going down in the hierarchy need to keep in mind what has been defined before - Javadoc viewer can help in reviewing the model (Tom to look for it and send a link) ** p3 File Systems - FileSystem: reworked importing/exporting etc ** p4 Operating System - There is a relationship to the filesystem it booted from - Can describe the set of installed OS on ComputerSystem ** p5 Processing and Job Queues - Multiple processes may be associated with a service - In v3.x all dynamic properties will move to StatisticalInformation - What are 'keys'? It gives an 'instance' flavor - Any new classes in 2.7 and later have 'key' while older classes have more compound keys - There is a more 'cleaned up' version. Andrea to send to the list ** p6 Boot services - May be reworked in v3.x. It is more of a placeholder at this stage - Parts are there just to allow vendor things to be added ** p7 Time - How to represent time; includes daylight time switching, etc. ** p8 Unix system ** p9 System Resources - At the moment it is mainly hardware definitions - When it was defined ('96) plug and play was important - In v2.9 software resources will start being added, and will start tackling software configuration, etc. ** p10 Message Log - How to go through logs - Also association with where the log is going. ** Other discussion - v2.9 is expected to be released in July - MOF: LogicalFile - No operations defined; just metadata - People were happy using their own operational/functional model - Is something is not defined it is likely to be an omission - There is always a problem of where to draw the line on management * Device review ** p1 UML - DeviceError became StatisticalInformation - 'Doors' are there to make sure that the device is in the correct physical state before doing some operation ** p2 Cooling & Power - Power to devices; associated cooling etc ** p3 Processor ** p4 Controllers - No serial controller; missing line ** p5 PCI devices ** p6 Logical Ports - Layer 1 element in ISO stack (0 is Physical) ** p7 Group ** p8 Protocol Controller - Attach/detach are more operational - But given certain states you might want to... - (State and behaviour WG relationship) - Different way of modelling this instead of using qualifiers ** p9 Network Adapters - A lot of this is deprecated ** p10 Fibre ** p11 Zoning - Zones are in Fabric which is instance of Network. The gist of it is trying to build on other aspects of model. * Other discussion Note: CIM is work in progress; things may look inconsistent for historical reasons. - Considering/planning move to UML and XMI. Qualifier mapping is the difficulty and how to express protocol for web services independent of the modeling stuff. Action: Tom to post URL to the preliminary v2.9 to ML - v2.9 cleans up diagrams etc, and sets the scene for 3.x - Profiles are starting to kick in (will be kicking in before 3.x) - The most likely point of interest is in the leaf nodes; they will not be that changed in 3.x Action: Andrea will send out Cisco's cleaned up version of the CIM. - JSIM discusion next week - And cleaned up model and semantics of lower nodes in 2 weeks time - How to start on gap analysis between CIM and Grid(OGSA)? - What is the timeframe of the UC-WG and what it addresses - Tom to follow up and send more details - Link up and make sure that priorities of components match - UC F2F last week - Next is August 18, 19, 20, which are the same dates as OGSA (and probably in the same general area) - There is a desire to coordinate with OGSA - Tom and Hiro to coordinate