Pegasus Enhancement Proposal (PEP)

PEP #: 319

PEP Type:  Functional

Title: DMTF Profile Registration Profile (DSP1033) support in OpenPegasus

Version: 1.3

Created: 29th Feb 2008

Authors: Venkateswara Rao Puvvada

Status:  Approved

Version History:

Abstract:  Adding support for DMTF Profile Registration Profile (DSP1033) in OpenPegasus.

Definition of the Problem

The Profile Registration defines the classes used to describe the DMTF profile registration and the version information of the profiles advertised as implemented for a managed system and components of the system.  The Profile Registration extends the management capability of the referencing profiles by adding the  capability to describe the registration and versioning of Common Information Model (CIM) profiles that are  implemented by CIM-based system and component-management instrumentation.

Currently Pegasus supports SNIA Profile Registration Profile 1.2 (PRP).  SNIA PRP is specialization of DMTF PRP. There is no direct support for DMTF PRP in Pegasus as of today. The SNIA Profile Registration Profile specializes the DMTF Profile Registration Profile adding the following classes:

• CIM_RegisteredSubProfile (subclass of CIM_RegisteredProfile)
• CIM_SubProfileRequiresProfile (subclass of CIM_ReferencedProfile)
  

DMTF PRP uses the following classes.

• CIM_RegisteredProfile - Provides information about Profile like organization, version ,name etc...
  
• CIM_ReferencedProfile -  Associates Autonomous profiles with component profiles.
  
• CIM_ElementConformsToProfile - Associates managed element with conforming profile.
  

• Central Class methodology is characterized by a CIM_ElementConformsToProfile association between every instance of a profile’s Central Class and the instance of CIM_RegisteredProfile that represents the profile.

• Scoping Class methodology and uses the CIM_ElementConformsToProfile association only between the “top-level” or Scoping Class instance of a connected set of instances and the instance of CIM_RegisteredProfile that represents the “top-level” or autonomous profile in a profile compliance hierarchy.

1. When DMTF Profile is added (by creating the instance of PG_ProviderProfileCapabilities) generate Referenced profile associations and Registered profile instances according to DMTF PRP (DSP1033). This will not change the existing SNIA PRP. Both profiles co-exists.
   
2. Support  addition of profiles dynamically to CIMOM.
3. When new profile is added or deleted re-register changed SLP 'RegisteredProfilesSupported' attribute without restarting the CIMOM.
4. When Provider Module or provider is disabled , enabled or removed, Registered profiles of the  conforming elements must be refreshed and  SLP re-advertisement shall happen.
   

Proposed Solution

Changes are required to InteropProvider to support DMTF PRP. Interop Instance provider shall support dynamic creation of  PG_ProviderProfileCapabilities instance.  ProfileOrganization needs to be checked (DMTF, SNIA or any other) while creating the Registered profiles and Referenced profiles. Currently we support both Scoping class and Central Class methodologies as mentioned in DMTF PRP (DSP1033).

New DMTF Autonomous profiles and  component profiles shall be added to the values of RegisteredProfile and 'RegisteredSubProfiles '  properties of PG_ProviderProfileCapabilities and PG_ReferencedProfileCapabilities class.

DMTF Autonomous profiles:

Base server
SM CLP Admin Domain
Modular Systems
Record Log
Computer System
Virtual System
etc...

DMTF Component Profiles:

Diagnostics
Policy
Sensors
Fan
Common Line Protocol Service
etc...

The following two new properties will be added to the PG_ProviderProfileCapabilities class.

SubProfileProviderModuleNames

This property will hold the the provider module names of implemented sub profiles. This allows implementation of component profiles in separate provider module. If no values specified in this property we assume component profiles are also implemented in the ProviderModule of implemented autonomous profile. This allows backward compatibility with existing implementations also.

SubProfileProviderNames

This property will hold the the provider  names of implemented sub profiles. This allows implementation of component profiles in separate provider. If no values specified in this property we assume component profiles are also implemented in the Provider of implemented autonomous profile. This allows backward compatibility with existing implementations also.

Whenever a new profile as added or deleted SLP has to advertise new attributes without restarting the CIMOM.  SLP re-registration must be done with  both Internal embedded SLP and external SLP.

Provider has to be registered before registering the Profile. Note that keys for PG_ProviderProfileCapabilities class are ProviderModuleName , ProviderName and CapabilityID of PG_Capabilities class which it inherits from.

When a new profile other than supported profiles in valueMaps of properties RegisteredProfile and RegisteredSubProfiles of PG_ProviderProfileRegistration class are used, they are advertised using SNIA PRP. DMTF PRP is used only when profile organization is DMTF. This allows backward compatibility with existing implementations.

InteropProvider supports both SNIA PRP and DMTF PRP. These profiles are implemented as built-in profiles. No compilation or runtime config option is introduced with this PEP as they both need to co-exist and the implementation differences are minimal.

CIM_RegisteredProfile and CIM_ReferencedProfile instances are created in Interp namespace (root/PG_Interop for Pegasus) . The purpose of the Interop Namespace is to provide a common and well-known place for a client application to discover all of the profiles that are supported within a given CIM Server.
CIM_ElementConformsToProfile instances can  created  in Interop namespace or in provider namespace (ie if provider is not in Interop namespace).  A typical configuration will have a single Interop Namespace and one or more Implementation Namespaces. An Interop Namespace should be established separate from Implementation Namespaces.  A profile implementation may span multiple Implementation Namespaces. If 'conformingElements' property of  PG_ProviderProfileCapabilities is NULL , the provider has to implement CIM_ElementConformsToProfile instances in its own namespaces. InteropProvider will enumerates instances of classes present in 'conformingElements' property (if not NULL) and associates them with Registered profiles.

Use cases

Example 1:

Registering the provider with profile capabilities.

(a) Create the instance of  PG_ProviderProfileCapabilities with known profiles from DMTF or SNIA.

instance of PG_ProviderProfileCapabilities
{
    ProviderModuleName = "DMTFBaseServerProfileProvidersModule";
    ProviderName = "DMTFBaseServerProvider";
    CapabilityID = "BaseServerProfile";
    RegisteredProfile = nn; // Base Server Profile
    RegisteredSubProfiles = {
        nnn, //  Fan Profile
        nnn}; // CPU Profile

    SubProfileProviderModuleNames = {
         "DMTFBaseServerProfileProvidersModule",
         "DMTFCPUProfileProvidersModule" };

    SubProfileProviderNames = {
         "DMTFBaseServerProvider",
         "DMTFCPUProvider"};

    ProfileVersion = "1.0";
    ConformingElements = { "DMTF_ServerSystem" };
};

nn/nnn  - See numbers in valueMaps for those corresponding properties in the PG_ProviderProfileCapabilities class.

(b)  Create the instance of  PG_ProviderProfileCapabilities with  profiles other than DMTF or SNIA profiles.

Example 2:

The following SMIRL pseudo-code defines an algorithm for determining what top-level profiles are advertised in an Interop Namespace:

PRE-EXISTING CONDITIONS AND ASSUMPTION

1. Assume the client has already determined and connected to the Interop Namespace

 // Step 1: Get the instances of all the CIM_RegisteredProfiles in the Interop Namespace.

 $AllProfiles[] = EnumerateInstances(“CIM_RegisteredProfile”, TRUE, TRUE, FALSE, FALSE, [“RegisteredName”])

 // Step 2: Get the names of all the CIM_RegisteredProfiles in the Interop Namespace that are referenced as the Antecedent of any instances of CIM_ReferencedProfile.

$DependentProfileNames[] = AssociatorNames(“CIM_RegisteredProfile”, “CIM_ReferencedProfile”,  “CIM_RegisteredProfile”, Antecedent, NULL )

 Step 3: Subtract the DependentProfileNames list from the AllProfiles list by erasing any profile name in the AllProfilesNames list that is in the DependentProfileNames list.

 for (#i=0; #i<$AllProfiles[].length; #i++)
 {
         for (#j=0; #j<$DependentProfileNames[].length; #j++)
        {
                  if ($AllProfiles[#i].getObjectName() == $DependentProfileNames[#j])
                 {
                        $AllProfiles[#i] = NULL;
                 }
        }
}

// Step 4: AllProfiles is now a sparse array that contains only the instances of profiles that are top level.

Example 3:

The following SMIRL pseudo-code describes the algorithm for determining the Central Class implementation instances for a profile advertised in an Interop Namespace. This algorithm depends on the Central Class methodology for advertising profile implementation.

DESCRIPTION:
A management application wishes to determine the ManagedElements that are instantiated by a particular DMTF profile, specifically the CPU Profile version 1.0.0.

PRE-EXISTING CONDITIONS AND ASSUMPTION

1. Assume the client has located and connected to the Interop Namespace.

Step 1: Select the instance of CIM_RegisteredProfile that represents the DMTF CPU Profile version 1.0.0.

 $profiles->[] = EnumerateInstances(“CIM_RegisteredProfile”, TRUE, TRUE, FALSE, FALSE, [“RegisteredName”])

 for (#i=0; #i<$profiles->[].length; $i++)
 {
      if ($profiles->[#1].RegisteredOrganization = “DMTF”) AND
               ($profiles->[#i].RegisteredName == "CPU Profile") AND
        $profiles->[#1].RegisteredVersion == “1.0.0”)  then
                $RegisteredProfile-> = $profiles->[#i];
 }

// Step 2: If the $RegisteredProfile-> variable is null, then return an error as there are no instances of CIM_RegisteredProfile that represent the
// DMTF CPU Profile version 1.0.0

// Step 3: Determine the ManagedElement (System) by traversing the ElementConformsToProfile association from the RegisteredProfile

 $ManagedElement->[] = Associators ( $RegisteredProfile->, “CIM_ElementConformsToProfile”,  NULL,  NULL,  FALSE, NULL)

 Step 4: If the $ManagedElement->[] array has no elements, return an error <ERROR! there are no instances of the Central Class implemented for this profile or the implementation has not utilized the Central Class methodology for advertising implementation conformance.>

// Step 5: The object name of more than one ManagedElement may be contained in the array returned. Examine the contents of $ManagedElement[] and save the name of the element of interest as $Name.

Example 4:

The following Storage Management Initiative Recipe Language (SMIRL) pseudo-code defines an  algorithm that a client application could use to determine profile implementation information for an instance of CIM_Fan. The instance of CIM_Fan could be any subclass of CIM_LogicalDevice that has been identified as a Central Class in a profile. Other ManagedElements, which are not subclasses of CIM_LogicalDevice, that are the Central Class of a profile can be found with this algorithm by using a different association between the Central Class and Scoping Class as defined in the profile. Profile RegisteredName, RegisteredVersion, and RegisteredOrganization information can be retrieved from the instance of CIM_RegisteredProfile yielded by this algorithm.

Find the Profile instance governing a particular instance of a CIM_Fan  class defined as the Central Class of the DMTF Fan Profile.

Preconditions - $fan identifies the fan about which we are interested in finding related profiles.

Note: This algorithm is not applicable if the SMIS (Storage Management Interface Specification) Multiple Computer System subprofile is implemented.

Assumptions - CIM_Fan is defined by a profile named "Fan Profile".
                     - DMTF Fan Profile defines CIM_Fan to be the Central Class.
                     - DMTF Fan Profile defines CIM_ComputerSystem (a subclass of CIM_System) as the Scoping Class.
                     - Cross-namespace associations have been implemented to support traversal between Interop and Implementation Namespaces.

 Postconditions - $subjectProfile (implementing profile) will contain the RegisteredProfile instance of the DMTF Fan Profile.

 Step 1) Check whether there exists an explicit ElementConformsToProfile to our target instance; this takes precedence over any scoping profile.

 $profiles->[] = Associators($fan.getObjectPath(),
                                            "CIM_ElementConformsToProfile",
                                            "CIM_RegisteredProfile",
                                             null,
                                             null,
                                             false,
                                             false,
                                             null);

//none directly associated
 if ($profiles->[].length == 0)
 {
           // Step 2) Find the scoping System instance (will work for subclasses like CIM_ComputerSystem).
          $scoping->[] = Associators($fan.getObjectPath(),
                                                     "CIM_SystemDevice",
                                                      "CIM_System",
                                                       null,
                                                       null,
                                                       false,
                                                       false,
                                                       null);

           $sysInstance-> = $scoping->[0];
           // Step 3) Find the autonomous profile for the scoping System instance.
           $profiles->[] = Associators($sysInstance->,
                                                      "CIM_ElementConformsToProfile",
                                                       "CIM_RegisteredProfile",
                                                       null,
                                                       null,
                                                       false,
                                                       false,
                                                      null);

             // save reference to the Autonomous profile for the CS instance.
             $autoRP-> = $profiles->[0];
             //now find the associated component profiles
             $profiles->[] = Associators($autoRP->,
                                                        "CIM_ReferencedProfile",
                                                        "CIM_RegisteredProfile",
                                                         "Antecedent",
                                                         "Dependent",
                                                         false,
                                                         false,
                                                         null);

              //look for fan profiles
              for (#i=0; #i<$profiles->[].length; $i++)
             {
                    //it’s a fan
                    if ($profiles->[#i].RegisteredName == "Fan Profile")
                   {
                               $fanProfiles->[$fanProfiles->[].length] = $profiles->[#i];
                    }
             }
             // Step 4) Find the scoping Fan Profile.
             for (#i=0; $fanProfiles->[].length; #i++)
            {
                      $associated->[] = Associators($fanProfiles->[#i],
                                                                       "CIM_ElementConformsToProfile",
                                                                       "CIM_Fan",
                                                                       null,
                                                                       null,
                                                                       false,
                                                                       false,
                                                                       null);
                      if ($associated->[].length == 0)
                      {
                             //no explicit ElementConformsToProfile, use scoping profile
                             $subjectProfile-> = $fanProfiles->[#i];
                      }
             }
 }
  else
 {
          //the defining profile is directly associated
          $subjectProfile-> = $profiles->[0];
 }

Enabling the Profiles support in Pegasus

InteropProvider services the all Profile Registration Profile class requests. It acts as both instance and association provider. InteropProvider is not enabled by default. The following build options enables the InteropProvider.

PEGASUS_ENABLE_INTEROP_PROVIDER is set to 'true'.

                 or

PEGASUS_ENABLE_SLP is set to 'true'.

                   or

PEGASUS_DISBALE_PERFINST is defined.

Note that when PEGASUS_ENABLE_SLP is defined  to 'true' or PEGASUS_DISBALE_PERFINST is defined , PEGASUS_ENABLE_INTEROP_PROVIDER can not have value 'false'.

Modules affected

SLP

Now SLPProvider will handle registrations for both Internal Embedded SLP SA and External SLP SA. SLPProvider will inform slp_agent whenever modifications to profiles are done. The following files will be modified.

pegasus/src/slp/slp_agent/peg_slp_agent.cpp
pegasus/src/slp/slp_agent/peg_slp_agent.h
pegasus/src/Providers/slp/SLPProvider.cpp
pegasus/src/Providers/slp/SLPProvider.h

Server

SLP re-registration with external SLP code from the CIMServer.cpp will be totally removed and now SLPProvider will handle all these registrations. Now CIMServer::startSLPProvider() method will be called only once which will start registrations in SLPProvider either with external SLP SA or Embedded SLP SA.
The following files will be modified.

pegasus/src/Pegasus/Server/CIMServer.cpp

Interop Provider.

InteropProvider will be modified to handle DMTF profile registration profiles. Changes are required to InteropInstanceProvider to support  creation of PG_ProviderProfileCapabilities instances dynamically. Whenever new profile is added or deleted InteropProvider invokes 'update' method of SLPProvider which will update the profile information. The following files will be modified.

pegasus/src/Pegasus/ControlProviders/InteropProvider/Software.cpp
pegasus/src/Pegasus/ControlProviders/InteropProvider/InteropProviderUtils.h
pegasus/src/Pegasus/ControlProviders/InteropProvider/InteropProviderUtils.cpp
pegasus/src/Pegasus/ControlProviders/InteropProvider/InteropProvider.cpp
pegasus/src/Pegasus/ControlProviders/InteropProvider/InteropConstants.h
pegasus/src/Pegasus/ControlProviders/InteropProvider/ElementConformsToProfile.cpp
pegasus/src/Pegasus/ControlProviders/InteropProvider/InteropProvider.h
pegasus/src/Pegasus/ControlProviders/InteropProvider/RegisteredProfile.cpp

ProviderRegistrationProvider

ProviderRegistrationProvider invokes InteropProvider's 'updateCache' method when  
   (a) provider or provider capability instances are created
   (b) provider or provider module or provider capability instances are deleted.
   (c) provider or Provider module is disabled or enabled.

Note: This method is invoked on PG_ProviderProfileCapabilities Object. This method is used for internal communication
between ProviderRegistrationProvider and InteropProvider.It allows InteropProvider to invalidate its cache for 
ElementConformsToProfile instances and calls SLPProvider's 'update' method to refresh advertisements if SLP is enabled.
This method is not part of PG_ProviderProfileCapabilities class definition.The following files will be modified.

pegasus/src/Pegasus/ControlProviders/ProviderRegistrationProvider/ProviderRegistrationProvider.cpp
pegasus/src/Pegasus/ControlProviders/ProviderRegistrationProvider/ProviderRegistrationProvider.h

Pegasus Interop Schema

New DMTF profiles will be added to the valueMaps of properties 'RegisteredProfile' and 'RegisteredSubProfiles' of class PG_ProviderProfileCapabilities.  New properties 'SubProfileProviderModuleNames' and 'SubProfileProviderNames' will be added to the class PG_ProviderProfileCapabilities to support implementation of component profiles by different Provider or ProviderModule other than the provider or ProviderModule which implements autonomous profile.The following files will be modified.

pegasus/Schemas/Pegasus/InterOp/VER20/PG_ServerProfile20.mof

Rationale

Rational behind this PEP is to implement the DMTF PRP (DSP1033) to support DMTF profiles. This will allow DMTF profiles to be added to CIMOM dynamically and added profiles are advertised through SLP.

Schedule

Discussion

Copyright (c) 2006 Hewlett-Packard Development Company, L.P.; IBM Corp.;
EMC Corporation; Symantec Corporation; The Open Group.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE SHALL BE INCLUDED IN
ALL COPIES OR SUBSTANTIAL PORTIONS OF THE SOFTWARE. THE SOFTWARE IS PROVIDED
"AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Template last modified: March 26th 2006 by Martin Kirk
Template version: 1.11