Abstract:

CIM includes the definition of policies and policy sets in its information model, although there are currently no policy languages that exploit those features. To address that need, the DMTF Policy Workgroup is considering CIM-SPL, a policy language, for standardization. It provides simple, but expressive policy constructs, and combines them with operators appropriate for traversing CIM models.

This concept PEP proposes to add a CIM-SPL processor to Pegasus, allowing Pegasus to process policy statements written in CIM-SPL.

Definition of the Problem

Most distributed computing environments today are very complex and time consuming for a human administrator to manage. For many emerging technologies, the management costs associated with deploying the technology and the time consumed by learning the details of the system outweigh the advantage gained by the use of the technology.

The policy based management approach provides a mechanism that can simplify the management of distributed computing systems, such as large computer networks, or storage systems. This simplification of the management functions is obtained via several elements of the policy architecture, including specialization, abstraction, and centralization. Centralization refers to the process of defining all the device provisioning and configuration rules at a single point, where they can be more easily managed, changed, and analyzed as a group to check for redundancies and possible inconsistencies. These policies can be defined to apply to many devices of the same type within the system, adapting to different environments according to local conditions that lead to choices of different actions. This is in contrast to provisioning and configuring each individual device in the distributed system separately, using the specific actions necessary for its particular use.

For these reasons, we believe it would be beneficial to introduce policy-based management into Pegasus.

Proposed Solution

As background, the goal of CIM-SPL is to provide a simple mechanism to define policies under the CIM model. Policies in CIM are defined as an aggregation of policy conditions and policy actions in a PolicyRule. Policy actions typically require arguments that are checked or sometimes computed in the condition. As such, the language must provide the ability to "carry forward" data computed in the condition to the action. CIM-SPL provides this ability.

In the next several paragraph, we provide some detail on CIM-SPL. For a more detailed discussion, please consult <1>.

CIM-SPL syntax

Import   :; 
Policy {
  Declaration {
		   (Optional)
		 (Optional)
  	}
  Condition {		(Optional)
    	  /* java-like boolean expression */
  	}
  Decision {		(Required)
    	  /* “small” workflow of action */
                                        /*   invocations                      */
  	}
}

The expression language of CIM-SPL supports all CIM intrinsic data types, including: Short, Integer, Long, Float, Double, Boolean, String, and Calendar. It also supports arrays of these data types.

CIM-SPL also provides a set of functions and operations, including:

• type cast functions (e.g., ToInt, ToFloat, ToBoolean),
• standard arithmetic functions (e.g., Plus, Max, Log),
• Boolean functions (e.g., And, Not, Equal),
• string manipulation (e.g., ToUpper, LeftSubString),
• calendar operations (e.g., GetDayOfWeek), and
• collection operations (e.g., MaxInCollection).

Decisions in CIM-SPL can take a number of forms:

  () 
	a PolicyAction evaluation without arguments
  ( = 
                                        <,  = >*) 
	a PolicyAction evaluation with at least one argument. 

	the identifier of another CIM Policy Set instance
 -> 	
	a sequence of PolicyAction evaluations
 | | 	
	concurrency "some" semantics
 && 	
	concurrency "all" semantics
 | 	
	conditional
(  )			
    To change precedence – all have equal precedence and are evaluated left to right.

We feel that the details of a real CIM traversal are out of scope for this document, but to provide additional clarity, we provide a pseudo-example. The syntax is correct, but the details of CIM traversal are abbreviated.

This example illustrates how one would encode the following policy:

If response time is greater than 3 seconds and the number of servers is less than 5, then increase the number of servers by 1

In CIM-SPL, it would be coded:

Import   CIM_X_XX_MOFFILE:AdminDomain; 
Policy {
Condition {  AdminDomain.ResponseTime > 3 
	   	      AND
		      AdminDomain.NumberOfServers < 5  	
  	}
  Decision {		
    	set.AdminDomain.NumberOfServers(NumberOfServers + 1) 
  	}
}

A second example illustrates this policy:

If file system is 85% full, then expand by 25%

In CIM-SPL, it would be coded:

Import   CIM_X_XX_XXXX:LocalFileSystem; 
Policy {
 Declaration { /* Macros to traverse HostedService associations to get
                      /* to FileSystemConfigurationService for ModifyFile and
                      /* StorageConfigurationService for CreateOrModify…
  	}
 Condition {  (AvailableSpace / FileSystemSize) < 0.25
  	}
Decision {   
	CreateOrModifyElementFromStoragePool(…) |
 	ModifyFileSystem(
     FileSystemSetting.NumberOfBlocksObject = 
                1.25 * FileSystemSize,…) 
  	}
}

For context, we provide the code necessary to modify the file system size, as noted in SMI-S 1.1.0 draft, page 929:

//
// Increase the size of a FileSystem
//
sub IncreaseFileSystemSize(IN CIM_FileSystem ,
IN uint64 ,
OUT CIM_Job )
{
//
// Get a client-side copy of the FileSystemSetting associated with the
// FileSystem
//
 = Associators(,
“CIM_ElementSettingData”,
“CIM_FileSystemSettingData”,
“ManagedElement”,
“SettingData”)-><0>;
//
// Use a subroutine to get a capability from the server.
//
&GetFSCapabilityFromFilesystem(, , );
if ( == NULL) {

return;
}
//
// Get the FileSystemConfiguration Service of NAS server using
// a HostedService association
//
 = Associators(->,
“CIM_HostedService”,
“CIM_FileSystemConfigurationService”,
“Antecedent”,
“Dependent”)-><0>;
if ( == NULL) {

return;
}
//
// Call FSCSCapabilities.GetRequiredStorageSize(NewGoal,
// DesiredUsableCapacity) to find out how large of a
// LogicalDisk is needed
//
 = .GetRequiredStorageSize(,
NULL, // no special requirements
,
,
);
//
// Get Underlying SE using ResidesOnExtent association
//
 = Associators(,
“CIM_ResidesOnExtent”,
“CIM_LogicalDisk”,
“Dependent”,
“Antecedent”)-><0>;
//
// If disk is not large enough, increase size of underlying SE
//
 = NULL;
if ( < .BlockSize * .NumberOfBlocks) {

necessary -- see storage extent recipes>
}
//
// The filesystem itself doesn’t need modification, so we’re done
//
}

As a related part of this project, we will consider whether the addition of libraries that accomplish common tasks is appropriate.

With that context, the concept proposal is straightforward: to include a CIM-SPL policy engine inOpenPegasus.

Should the Concept PEP be approved, many of the details with be set forth in the functional PEP. However we provide a brief, high-level description of the proposed implementation. We fully expect that some details will change upon further discussion.

The CIM-SPL policy engine will be a CIM instance provider for instances of the CIM Policy Class. As such, it can utilize existing Pegasus functions to add, delete and persist policies which, we expect, will be encoded as MOF files.

To evaluate conditions, the policy engine will draw on data available to the CIM server. Such data includes, but is not necessarily limited to, indications received internally and metrics retrieved using low-level interfaces.

Policy evaluation can be triggered using a number of mechanisms. In one case, the policy engine will analyze the conditions for the loaded policies, and subscribe to the relevant indications. Upon receipt of an indication, the engine evaluates the policies. In another case, an administrator might manually trigger evaluation.

Finally, we understand that we have provided only a cursory discussion of the implementation, and we have deferred many of the architectural decisions. As we note above, should the Concept PEP be approved, many of the details with be set forth in the functional PEP.

<1> For more information on CIM-SPL, please consult: http://www.dmtf.org/apps/org/workgroup/policy/documents.php. DMTF membership is required.

Rationale

Design decisions to be discussed as part of a functional PEP.

Schedule

To be determined in the functional PEP.