Ellen Stokes stokese@us.ibm

1. Common Resource Model(CRM)snapshot of information to be released as a GGF working doc (OGSA WG / CRM BOF) for the March 2003 GGF meeting Ellen Stokes stokese@us.ibm.com

2. Manageability and OGSA • Manageability defines information that is useful for managing a resource • Common Resource Model defines how to model resources’ manageability • Every manageable resource is represented by a grid service • Each resource instance has a unique identifier • State data is exposed as service data elements (SDEs) • Operations are exposed as grid/web services operations • Basic building blocks are xml, xsd, wsdl, and gsdl • Leverage CIM schema

3. Composing a Resource as a Service • wsdl (open content model) and xsd describe manageable attributes of a resource called service data • Basic manageability port types applicable to resources • Lifecycle, identity, relationship • Aggregation of the service data, the manageability port types, and the grid service port type yields basic port types of resources that form the basic set of models for the Common Resource Model • A resource may have more than one binding to access that resource’s manageability information • A resource may support more than one service implementation • e.g Native, SNMP, CIM, RMC, etc • A resource can still be accessed (outside OGSA) using its existing implementation, resource definition, and access interface, e.g. SNMP, CIM, etc.

4. Approach • Use CIM models as base for resource models as applicable • Roughly, class is port type, properties of class are service data of the port type, methods of class are operations of the port type • Not a 1-1 class-portType map; service (course grained) needs to be composed from finer grain parts • Express in WSDL/GSDL as grid service • Managed resource port type from which other resource port types are derived • Mix in the base grid service port type • gridService (required for grid behavior) • Mix in other CRM port types as needed • identity relationship, lifecycleState • CIM as the basis for the meta-model and resource schemas • Add, delete, change as necessary, but not be constrained by CIM or DMTF work • e.g. use constructs from xml/xsd where similar ones exist in CIM

5. XSD data type extensions • New data types needed to express manageability information • refinements of datatype integer to convey the meaning of the integer data as well as the range of valid values • counter • non-negative integer that monotonically increases until it reaches a maximum value, when it wraps around and starts increasing again from zero • minimum value is implicitly zero; its maximum value is specified as an XML attribute of the counter • gauge • integer that may increase or decrease, but can never exceed a minimum or maximum value • maximum and minimum values for the gauge are specified as XML attributes of the gauge • Other common data types can be expressed through existing XML data types • array • bit or binary • octet

6. XML attributes • General and useful versioning capabilities for port types, service data, operations, and bindings • version • majorNum.minorNum.patch (includes compatibility rules) • deprecated • Construct is tolerated, but not recommended and may be superceded • experimental • Available for experimentation and at some point will either become part of a formal release or removed entirely • Unit of measure • Units • Unit of measure for the value of a XSD schema element used in the service data or parameters of operations • Well-known set with extensibility

7. Basic Manageability Port Types • Needed to manage the resource • lifecycleState • identity • relationship • Others defined • As CIM schema is dissected, e.g. operational operations (start/stop/resume/pause) • By Grid service spec, e.g. grid service, notification • By other OGSA components, e.g. policy, logging/metering

8. Base Manageable Port Types

9. lifecycleState Port Type Exists Stopped Starting Failed Stopping Started • Get/set the lifecycle state (service data) that the resource is in • stopped, starting, started, stopping, failed • Each lifecycle state has additional information about its operational state • stopped state: startable, recovered • starting state: OK, error • started state: OK, predictiveFailure, stressed, degraded, maintenance • stopping state: OK, error • failed state: maintenance, supportLoss, nonRecoverableError

10. Lifecycle Attributes • Additional XML attributes may decorate the manageability information of a resource • valid: when a port type, service data, or operation is valid • changeable: when service data can be changed (from an application or mgmt tool perspective) • latency: when an operation or the setting of a service data value takes effect • volatile: how often service data value changes (from the resource’s perspective) • The grid spec lifecycle attributes goodFrom, goodUntil, and availableUntil are complementary

11. Directly and Indirectly Managed Resources • There are lots of resource instances in the grid – question is which to manage how in scalable fashion • Major or higher level manageable resources in the system are registered with the registry and handle resolver (direct) • Registry function for more numerous smaller resources are delegated to the major or higher level resources containing them (indirect)

12. Manageable Resource Identity • Each resource instance is uniquely named by a GridServiceHandle (GSH) in the form of a URI • GSH for a manageable resource is called the manageable resource ID (MRID) • CRM defines new URI scheme with 2 sets of information to enable indirect management and identify properties to simplify identity mapping • Identity of the resource • Identity of the root manageable resource

13. Identity Port Type • Indicates which properties of the manageable resource form its identity and which are useful keys for finding manageable resources of that type • Contains 3 service data elements • rootResourceType, the manageable resource type of the root manageable resource • identityProperty, one or more properties that are contained in the MRID for a resource • searchProperty, zero or more properties that are likely to be used for searching for a manageable resource

14. Relationships & Dependencies • Relationships describe which resources are connected and what type of connection exists between resource instances • Relationships are discovered through the relationship port type and its relatedResource service data element • Relationship port type allows a view of relationships as they are known by the resources at each end of the relationship • Set of predefined relationship types • Hosts • Contains • Federates • Aggregates • Uses • Implements • Dependencies describe how one resource depends on another • Specifics still under development

15. Relationship Types: hosts & contains • Hosts and Contains are used to describe the physical containment of resources in a system • Hosts is about one resource providing the environment for another resource • Resource A hosts another resource B if resource A provides an environment in which resource B is created and runs • Contains is about how one resource is built from set of contained resources • A resource may actually consist of a number of other resources and, therefore, is said to contain them • Lifecycle implications • Hosts implies relatively independent lifecycle from the hosted resource • Contains implies the same lifecycle as the container

16. Relationship Types: federates & aggregates • Federates describes the logical structure of an application or solution • Where a number of resources in different hosting environments are used together to produce another resource, then that resource is said to federate the other resources • Federates does not imply anything about the lifecycle of the federated resource except that the resource exists • Aggregates describes how resources are grouped together • Where a number of resource are grouped together for some purpose, then that resource is said to aggregate the other resources • Aggregated resource do not know about each other unless some other relationship between them exists • Aggregates does not imply anything about the lifecycle of the aggregated resource except that the resource exists

17. Relationship Types: uses & implements • Uses describes where one resource makes use of the functions of another • one resource uses another resource in order to perform its functions, e.g. a user management system may use an LDAP directory to hold user information • Implements describes the way that one resource is actually implemented;useful to bridge between a logical, functional view of the system and its physical implementation • one resource is used to implement the function of another, e.g. a database server may be implemented as a Windows service

18. CRM Tooling • Runs under WSAD (Eclipse base) • UML-like tool for visual composition of a resource • Seed tool with • port types from CRM spec • port types derived from CIM classes • CIM MOF as input • Other model input over time, e.g. SNMP • Output • Grid service definition (gsdl) • Service implementation proxy

19. The End