Common Management Model 25 June 2003 GGF CMM Workgroup

Charter Provide a set of port types that build on and supplement the OGSI specification that are of broad and general use for management Deliverables: Specification (Recommendation document) Port types of broad and general use: lifecycle state, relationships; includes XML associated XML attributes Port types that are canonical and useful for multiple services, such as operational (start/stop/pause/resume) Mechanism by which port types for higher value applications and /or resource managers (provisioning, work scheduling, etc) are extended to make use of the detailed manageability information from existing instrumentation / models Specification Primer (Community Practice document) What we will not do Define single coalesced resource information model Define domain specific schema Define XML/WSDL representations for existing models, e.g. CIM 25 June 2003 GGF CMM Workgroup

What is CMM? Entities such as mgmt appls or RMs RM3 Meta-OS Services 2. OGSI / WS extensions Lifecycle state models Relationships -Associated XML attributes for lifecycle 6. Modeling practices Entities such as mgmt appls or RMs 4A. Canonical port types - common to multiple RMs 5. Canonical services used by multiple RMs (factored out from 4.) RM2 RM3 RM1 Meta-OS Services 4. Resource Managers (RM) 3. Resources, canonical factoring (PTs), grid behavior, e.g. schema and/or operations such as operational; guidelines Rg Rn Resources, native instrumentation Key Red=Not in CMM realm Green=within CMM realm Blue=Domain defined 25 June 2003 GGF CMM Workgroup

Process Date Deliverable 29 Aug 2003 Internal version of community practice document, not reviewable; input for development of port type specification Every other week conference calls through Aug 2003 15 Sep 2003 Outline / strawman port type specification 6-8 Oct 2003 GGF9 (Chicago): 2 sessions (1) Discuss community practice document (2) Technical work session on port type specification 8-10 Oct 2003 (noon-noon) Face-to-Face; Chicago, adjacent to GGF Port type specification Feb/Mar 2004 GGF10: reviewable drafts of community practice and specification documents June 2004 GGF11: community practice and specification documents finalized for GGF review 25 June 2003 GGF CMM Workgroup

BACKUP 25 June 2003 GGF CMM Workgroup

CMM Define the port types / XML attributes that are commonly needed for management, e.g. Port Types: Lifecycle state, Relationships XML attributes: Lifecycle BaseManageableResource PT (from which every manageable resource extends?) Extensible lifecycle state, complements OGSI lifetime service data Relationships/dependencies between services Use of OGSI Service Group for locating fine-grained resources Define the mechanism by which port types for higher value applications and /or resource managers (provisioning, work scheduling, etc) are extended to make use of the detailed manageability information from existing instrumentation / models Resources are expressed as services Allow existing resource models to be used and exposed in port types Assume existing models have XML/XSD representation? Canonical factoring of resources (schema/operations) as needed by domain specific RMs Identify additional canonical services factored out from across multiple domain specific RMs e.g. Operational port type (start, stop, pause, resume, …) 25 June 2003 GGF CMM Workgroup

CMM Specification <insert proposed outline> 25 June 2003 GGF CMM Workgroup

CMM Community Practice Document Describe existing resource information models CIM SNMP JMX Unicore Glue Existing proposed port types (unfactored) GRAM Unicore UPL CRM <Revisions + other sections later> 25 June 2003 GGF CMM Workgroup

GGF CRM BOF + Follow-On Meeting Summary Purpose: reach agreement on a useful but narrow scope to complete work within 2 months Common ground: Specification for items of broad, general use, e.g. lifecycle, relationships (intent is Recommendation document) [2.] Best practices for modeling resources (intent is Community Practice or Informational document) [3./6.] Not redefine a single coalesced model Not re-do low-level models, but instead must allow existing models to be used and exposed Concentrate on higher level resources - drawing out the common parts into a new model, but allowing drill-down onto the underlying detail Consider how function is split between Resources, Resource Managers, Meta OS Services – and how the needs of each are met by the other Domain specific (higher order) schemas done in other GGF WGs with advice/counsel from folks involved in this WG [4./4A./5.] Note: begs schema coordination questions across GGF groups Low level schema / XML representations, e.g. CIM, done at DMTF [1.] 25 June 2003 GGF CMM Workgroup

Summary of relevant sections from CRM Specification 17 Feb 2003 25 June 2003 GGF CMM Workgroup

Base Manageable Resource Port Type OGSA port types GridService Notification HandleResolver ServiceGroup Locate Relationship LifecycleModel CMM port types BaseManageableResource 25 June 2003 GGF CMM Workgroup

lifecycleModel Port Type Container for lifecycle states; there may be multiple models, but only one for a given resource’s port type and its instances Example: Get/set the lifecycle state (service data) that the resource is in down, starting, up, stopping, failed Each lifecycle state has additional information about its operational state down state: restartable, recovered starting state: OK, error up state: idle, busy, degraded stopping state: OK, error failed state: dependencyFailure, nonRecoverableError Exists Down Starting Failed Stopping Up 25 June 2003 GGF CMM Workgroup

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 25 June 2003 GGF CMM Workgroup

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 (UML Association Stereotypes) Hosts Contains Federates Aggregates Uses Implements Dependencies describe how one resource depends on another 25 June 2003 GGF CMM Workgroup

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 Both of these relationships have a cardinality of one-to-many A resource can only be hosted or contained by a single resource A resource can either be hosted or contained, but not both Lifecycle implications Hosts implies relatively independent lifecycle from the hosted resource Contains implies the same lifecycle as the container 25 June 2003 GGF CMM Workgroup

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 The new resource introduces new management operations and possibly new function 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 Homogeneous or heterogeneous resource types Aggregated resource do not know about each other unless some other relationship between them exists A resource may be part of any number of federates or aggregates relationships Federates and aggregates do not imply anything about the lifecycle of the federated resource except that the resource exists 25 June 2003 GGF CMM Workgroup

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 One resource may use another and also be used, either directly or indirectly, by that other resource 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 The implementing resource unit must be running for the implemented resource to be running The implementing resource may be created dynamically when the implemented resource is run, for example an operating system process, or it may persist between invocations A resource may be part of any number of uses or implements relationships 25 June 2003 GGF CMM Workgroup

Notes 1. XML/XSD/WSDL best defined by model owners 1./3. Interaction between grid/canonical and natively instrumented resources needs further design investigation; possible options: Natively instrumented resources derive from grid/canonical resources (derived from base manageable resource and grid service) Pro: consistent behavioral model Con: unnatural derivation for natively instrumented resources Grid/canonical (base manageable) resources point to natively instrumented resources (using service locator, also need way to specify/discover instrumentation type?) Pro: use of natively instrumented resource in natural way Con: inconsistent behavior model 3. Canonical factoring for properties / operations as needed in support of 4.; more comprehensive over time 4. Defined by domain specific owners 4A. Factoring is functional 5. complex queries across multiple resources, (directed at a particular type of registry?) e.g. find me disks serviced by Linux OS that have 1GB free space 25 June 2003 GGF CMM Workgroup

Out of Scope for specification; Potential use for community practice 25 June 2003 GGF CMM Workgroup

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 25 June 2003 GGF CMM Workgroup

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 25 June 2003 GGF CMM Workgroup

The End 25 June 2003 GGF CMM Workgroup