27 January 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
27 January 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
27 January 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.
27 January 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
27 January 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
27 January 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
27 January 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
27 January Base Manageable Port Types
27 January lifecycleState Port Type 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 StoppedStarting StartedStopping Exists Failed
27 January 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
27 January 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)
27 January 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
27 January 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
27 January 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
27 January 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
27 January 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
27 January 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
27 January 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
27 January The End