1. Common Management Model
25 June 2003
GGF CMM Workgroup

2. 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

3. 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

4. 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

5. BACKUP
25 June 2003
GGF CMM Workgroup

6. 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

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

8. 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

9. 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

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

11. 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

12. 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

13. 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

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

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
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

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
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

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
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

18. 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

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

20. 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

21. 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

22. The End
25 June 2003
GGF CMM Workgroup