Pegasus Enhancement Proposal (PEP)

PEP #: 244

Title: Providing SMI-Server Profile through OpenPegasus

Created: 1 October 2005

Authors: Karl Schopmeyer

Status:  draft

Version History:

Abstract: SNIA specification (SMI-s) is driven by the concept of profiles. One of the key profiles is the CIMServer itself.  This requires a defined set of classes and instances to report on the CIM server and its capabilities.  This PEP introduces a solution to implement these classes and instances for Pegasus.

Definition of the Problem

Overview

The SNIA SMI-s specification provides for a profile of features that are common across all SNIA providers (CIMServer and providers) and that could be logically provided by a single implementation rather than each user of Pegasus being required to do their own implementation of these features.  Further, this set of features are tied to the CIMOM itself, not to gathering data from outside data sources.  The feature set includes the following set of model functionality primarily from the CIM_Interop model of the CIM_Schema.

There are now a significant number of users of Pegasus for the SMIS environment and the SNIA Server profile (SMIs Specification v 1.1, section 8.1.4.1) is a common need for all of the profiles.  This work is proposed as a common provider in Pegasus for the following reasons:

• This is the one profile that all SMIS compliant  providers must satisfy.
• It is based on the CIM_Interop model of the CIM_Schema which is a part of the DMTF released CIM model
• It provides information largely about the CIMServer environment itself
• A considerable part of the information generated for this profile is required not only for the SMIS server profile but also as  attributes for the DMTF defined SLP template.  Thus, even if the server profile were not required as a standard component, much of the information generation would be required to be able to generate and advertise the SLP template.
• Much of the information in the server profile is already being generated by Pegasus through the Interop control provider and it seems logical to complete this and create a single complete SMIS server implementation.

This PEP documents the SMI-s profile requirements and the completed and proposed components to provide this profile

Requirements

The requirements for implementing this profile are driven by the SMI-s 1.1 specification section 8.1.4.1 .

The Major Functions of the Server Profile

NOTE: See the SNIA SMI-s specification, version 1.1 for the complete definition of this SNIA profile.

This profile provides the following major functionality:

1. Information on the CIMServer itself through the following classes: CIM_ObjectManager, CIM_Namespace, CIMCommunicationMechanism and associated associations.

2. Information on Registered Profiles through the CIM_RegisteredProfile, CIM_RegisteredProfile and associated classes. This information is used by a CIM Client in the SMI-s profile to determine what management functionality is supported by the CIM Server.  Note that the RegisteredProfile information is used by the discovery process so that a client can determine the types of entities supported by inspecting the RegisteredProfilesSupported attribute returned for the SLP entries. This identifies the types of entities (e.g., devices) supported by the CIM Server.

3. Information on software products and components through the CIM_Product, CIM_ProductSoftwareCOmponent, CIM_ElementSoftwareIdenty etc. classes.

The Server Profile Classes

The SNIA SMIS specification provides a single profile named the server profile that must provide instances of the following classes. Note that today there are two versions of this profile of interest and the version in which the requirement first appears is also shown below.

CIM_Operations Requirements

This profile requires the following operation profile components:

1. Association Traversal
2. Basic Read
3. Indications

The following functional profile elements are not required:

1. Basic Write
2. Instance Manipulation
3. Qualifier Declaration
4. Query
5. Schema Manipulation

Requirements for each Class

CIM_ObjectManager -  The instance of the ObjectManager class that represents this CIM Server.  The DMTF requires that the name field be a unique identification for the CIM Server.. In additions to the key properties, the following properties for this class are required:

• Description
• OperationalStatus
• Started

CIM_CIMXMLCommunicationMechanism - In addition to the key properties, the following properties are required for instances of this object:

• CommunicationMechanism
• Version
• CIMValidated
• FunctionalProfilesSupported
• MultipleOperationsSupported
• AuthenticationMechanismsSupported
• OperationalStatus

CIM_Namespace -  Must provide instances representing all of the namespaces in the environment. 

NOTE: The spec says all.  It might be an issue that an implementation would want to keep some namespaces private.  There is no resolution for this now.  In addition to the key properties, the following properties of this class are required.

• ClassType

CIM_RegisteredProfile - This is one of the classes that determines the entities/scenarios that are capable of being managed by the CIM Server.  It is closely tied to the other classes of CIM_RegisteredSubProfile, CIM_ReferencedProfile, and CIM_SubProfileRequiresProfile. Together these classes and associations provide the definition of profiles and the relationship between profiles and subprofiles.

A Profile is modeled using the RegisteredProfile class. One instance of profile is created for each ManagedElement that is covered by a profile and is managed by the Server. RegisteredProfile instances can be found by enumerating RegisteredProfiles within the interop namespace. A client would find all profiles supported by the Server by enumerating RegisteredProfiles, enumerating RegisteredSubprofiles and subtracting the second list from the first list. This yields the list of Profiles supported by the ObjectManager.

For each Profile instance, the subprofiles that have been implemented (for the instance) should be identified via the SubprofileRequiresProfile association. Subprofiles are modeled using the RegisteredSubProfile class. However, the RegisteredVersion property of subprofiles shall be the same
as the RegisteredVersion in the parent profile.

NOTE: The registered profile Class defines a profile in terms of 3 properties (RegisteredOrganization, RegisteredName, RegisteredVersion). Together these define a profile. An example might be snia, server, 1.0.0.  However, the key property is instanceID.  The three other properties are required but not part of the key.  There is nowhere in the SMIS-s specificaiton that I can find any requirement that there be only one instance with a unique organization, name, and version.  With multiple profiles being registered, it seems highly likely that there could be multiple instances registered with the same organization, name, and version unless there were internal protection in the CIM Server.   I assume that the intention of the specification would be only one instance but that should be clarified both for the SMI-s specification and for the implementation.

In addition to the key property, the following properties of this class are required:

• RegisteredOrganization
• RegisteredVersion
• RegisteredName
• AdvertiseTypes

CIM_RegisteredSubProfile - See RegisteredProfile

CIM_ReferencedProfile - See RegisteredProfile

CIM_SubProfileRequiresProfile - See RegisteredProfile

CIM_ElementConformsToProfile - The ElementConformsToProfile association ties the “top-level” Profile (RegisteredProfile) to
the scoping ManagedElements. These ManagedElements are typically ComputerSystems or
AdminDomains. A single ManagedElement may have zero or more ElementConformsToProfile associations to RegisteredProfiles. Regardless of the number of associated RegisteredProfiles the ManagedElement represents one set of resources. So for example, consider a ManagedElement that is a System that supports both the Array and Storage Virtualizer profiles. If one asks for the total amount of mapped capacity, the answer applies to both Array and Virtualizer and is not additive.

Note that in the SMIs specification this is defined as the one association that crosses namespaces. 
CIM_SoftwareIdentity - Each RegisteredProfile and RegisteredSubprofile instance shall be associated to one (or more)
SoftwareIdentity instances containing information about the software packages required to deploy the
instrumentation (including providers). These are associated using ElementSoftwareIdentity.
SoftwareIdentity instance may optionally be associated to Product instances representing a software
product.

In addition tothe InstanceID,the following Properties are required for each instance of this class:

• Name
• VersionString
• Manufacturer
• Classifications
   

CIM_Product - See SoftwareIdentity

Namespace Requirements

The specifications define specific namespaces for a number of the classes as follows:

Notes:

1. It is implied in the specification that this class exists in the interop namespace.  However, that is not clearly stated.  Further, it is not clear that this is the long term solution we want to support this class in general, not simply as a component of the Interop namespace. 

2. The SMI-S spec implies that this is in the interop namespace.  Clearly there are some issues here in that this is a very general association that will tie services that may exist in multiple different namespaces to the system class. 

SNIA SMIsScripting Requirements

Typically the SNIA specification includes a number of scripts that represent a common approach to selected services involving multiple objects.

The Server Profile includes the following scripts:

1. Find Servers Supporting a Given Profile
2. Enumerate Profiles Supported by a Given CIM Server
3. Identify the ManagedElement Defined by a Profile
4. Determine the SNIA version of a Profile
5. Determine the Subprofile Capabilities of a Profile
6. Find all Profiles and subprofiles on a Server
7. Segregate a SAN Device Type

In order to be compliant with the DMTF certification testing, the implementation must demonstrate the capability to execute the operations represented by these scripts.  At the same time, these are client scripts.  It is proposed that the end-end tests of the pegasus environment will implement these scripts to insure that the requirements are met.

The only impact on the provider is to assure that it does return the proper responses.

Proposed Solution

Design Solution for the Server Profile in OpenPegasus

General

The goal (and one achieved by the current implementation) is to make it so that Providers do not have to implement ANY of the Server profile classes, and instead can get that functionality by creating instances of the ProviderProfileCapabilities (and optionally one instance of ProviderReferencedProfiles) as part of provider registration. The one exception is that, depending on the model used by the provider, the provider may have to implement the ElementConformsToProfile association in the provider's namespace.

There are some general requirements which this implementation must meet including:

1. A Pegasus implementer must be able to disable the components of this profile in favor of components developed by that developer.  This will allow a Pegasus implementation that implements the profile in some other manner to continue to use that implementation.

2. The implementation must be capable of existing with other SMI-s and possibly other DMTF profiles.  In particular, it MUST NOT capture total control of classes that might require implementation and/or information defined in other profiles.  The general solution to this issue is to implement in general in PG_* subclasses of the defined CIM_ Classes.

CIM Object Manager Information Classes and Associations

These classes are all provided by Pegasus within the Interop namespace (PG_Interop).  The classes may or may not exist in other namespaces but the implementation will not return instances for any other namespace.

CIM_ObjectManager -  This is implemented in the Pegasus Interop  Control Provider. Today it meets the requirements of the DMTF specification and the SMIS specification for this class. This provider creates a single instance of the CIM_ObjectManager class as a part of the first access (enumerate) of the class if no instances exist in the repository and persists this instance in the repository.  The provider does not support modification or deletion of this instance.  This instance is persistent because several of the fields are required to be permanent.  In particular:

• Statistics - This is a boolean that controls generation of statistics. Once set, it retains this state through CIMServer restart
• Name - This must be a unique ID that is persistent.  The concept is that this is a unique identification for the CIM Server.  The provider creates this property from a combination of  organization ID (ex. PG) and a guid creating a unique identification.
• Operational Status

CIM_Namespace - This class has been implemented as a part of the Pegasus Interop Provider.  It provides the capability to create, delete and enumerate Pegasus Namespaces.  The properties provided include:

• SystemCreationClassName
• SytemName
• ObjectManagerCreationClassName
• ObjectManagerName
• CreationClassName
• Name - Name of the Namespace (ex. root/PG_Interop)
• ClassType - Within Pegasus today this is defined as "Unknown" because Pegasus does not have a mechanism to input ClassType with the original definition of a class through the MOF compiler (There is no mechanism in the compiler today to define the type with namespace creation)

ISSUES:

Pegasus implements a subclass of CIM_Namespace, (PG_Namespace) which adds additional properties to provide the capability to create and maintained shared namespaces.

CIM_CIMXMLCommunicationMechanism - This has been implemented in the Pegasus Interop Control Provider. Today it meets the requiremetns of the DMTF specificaiton and the SMIS specification for this class. The provider creates instances of this class for each externally available communication mechanism. Thus, typically there would be an instance for both the http and https ports if they were available.

Pegasus Implements the following properties in this Class:

• SystemCreationClassName
• SystemName
• CreationClassName
• Name
• ElementName
• COmmunicationMechanism
• Version
• CIMValidated
• FunctionalProfilesSupported
• MultipeOperationsSupported
• AuthenticationMechanismsSupported
• OperationalStatus
• FunctionalProfileDescriptions

Pegasus implements a subclass of this class (PG_CIMXMLCOmmunincationMechanism) that includes extra properties to define more information on the CommunicationMechanism.

ISSUES: None

COMMENT: No instance is provided for the local communication mechanism that is available within Pegasus through the client connectlocal() function.  This is considered Pegasus internal.

CommechanismForManager - This is an association between the CIMObjectManager and the CIMXMLCommunicationMechanism instances.  It is implemented as an instance and association provider in the Interop Control Provider.

This has been implemented for some time BUT was not registered in Pegasus 2.5.0.  This proposal would require adding the registration to the CIMOperationDispatcher and adding the test for this association to the interop tests.

NamespaceInManager - This association between CIM_Namespace and CIM_ObjectManager is implemented in the Pegasus Interop Control Provider today and is active and included in the Interop Provider.

ISSUES: None

HostedService - This association represents the linkage between the system and services hosted by that system.  In the long term, we expect that each service desiring an association with CIM_System should "activate" a corresponding instance of this association. For associations such as this where, in fact, the antecedent and dependentt references are not closely linked in lifecycle, and where the lifecycle of the antecedent is expected to be long and dependable (CIM_System should be an active class whenever the system is operating) it would appear that it is part of the role of the class representing the dependent role to activate an association.  At the same time, it is expected that these associations will NOT BE persistent so that they must be redefined at each boot of the system, one of the activities of actually creating the dependent instance itself.  However, it cannot be the role of any particular service to take responsibility for the instance/association class for this association, there must be a single provider since in general Pegasus does not support multiple providers for a single Class. The alternative is to subclass the association so that there can be multiple providers

HostedService is implemented as a subclass of CIM_HostedService (PG_HostedService)

ISSUES:

1. In the proposed changes that have been tested, the CIM_HostedService is implemented in the Interop Control provider.  Since the long term goal is for each service desiring this association to provide the associations required.  Therefore, in the long term it seems logical that subclasses of the association should be implemented to allow multiple providers.

2. There is an outstanding issue with crossNamespace associations (See below for more discussion).

3. The Windows provider for CIM_Computer system (the logical subclass of CIM_System to provide instances of CIM_System) is NOT IMPLEMENTED for windows today.  (See Below)

CIM_System - This class has been previously implemented by a Pegasus providers.  However, the class has not been equally implemented in all platforms in OpenPegasus.  In particular, this class is not implemented for Windows.  Further, the class in implemented today in the "normal" namespace root/cimv2. 

In order to meet the requirements of SMI-s the CIM_System MUST exist in the Interop namespace.  Today in the Pegasus 2.5.0 tree, the CIM_System class does NOT exist in the interop namespace. Typicall it exists in root/cimv2.

ACTION: Implement the windows stub so that we provide at least enough information to support an association between this class and the objectManager (HostedService).  Supporting other information from the manager should be considered by Pegasus for a number of platforms but not part of this PEP.

CIM_ServiceAccessPoint - This is an association between CIM_System and CIM_ServiceAccessPoint and represents. The CIM_CIMXMLCommunicationMechanism is a subclass of CIM_ServiceAccessPoint (CIM_ServiceAccessPoint -> CIM_ObjectManagerCommunicationMechanism -> CIM_CIMXMLCommunicationMechanism and is therefore a CIM_ServiceAccessPoint.

Today this association is NOT implemented in Pegasus.  To make this available for the server profile it or a subclass must be implemented. 

This class is implemented as part of this work as PG_HostedAccessPoint in the Interop Provider. and defines the realtionships between CIM_ComputerSystem and the instances of CIMXMLCommunicationMechanism.

The RegisteredProfile Classes and Associations

This includes the following classes and associations:

1. CIM_RegisteredProfile
2. CIM_RegisteredSubProfile
3. ReferencedProfile (association)
4. SubProfileRequiresProfile (association)
5. ElementCOnformsToProfile (association)

All of these classes represent the existence of certain management functionality.  Effectively creating instances of these classes is part of defining the existence of this management functionality within the CIM Server.  Typically it would appear that these profiles should be defined as part of  registering the associated providers that represent the implementation of this management functionality.   In order that the profile for the CIM Server itself, the server profile be complete, it will be required that the Pegasus implementation implement the instance of registered profile for the server profile.  This will be a single instance with the properties:

• InstanceID - Unique identification
• RegisteredOrganization = SNIA (Enum 12)
• RegisteredVersion = 1.1.0 (For the SMI-S specificaiton 1.1)
• RegisteredName - Server
• AdvertiseTypes = (3)

Note that there is an issue with this instance within some organizations today using the profiles.  This element is one end of the assocations ElementConformsTo and TBD.  However, today, many implementors are implementing these other entities as static mof in which case, the InstanceID of the RegisteredProfile is NOT available at the time the MOF is created.  In order to get around this issue for Pegasus 2.5.x, a test is included so that if the Server profile instance is already registered, it will NOT BE created by the Interop Provider

NOTE: There is another issue in that SNIA has NOT placed any requirements on issues of duplicate profiles.  Thus, there is nothing limiting a server from having multiple instances of the Server Registered profile (remember that the properties RegisteredOrganization, RegisteredName, RegisteredVersion are NOT key properties so that syntatically it is legal to create instances with the same information in these fields but different InstanceIDs.

RegisteredProfile - This association is implemented as PG_RegisteredProfile in the InteropProvider.  The instances are dynamically created using instances of  the PG_ProvviderProfileCapabilities  and PG_ProviderReferencedProfiles classes.

RegisteredSubProfile -  This association is implemented as PG_RegisteredSubProfile in the InteropProvider.  The instances are dynamically created using instances of  the PG_ProvviderProfileCapabilities  and PG_ProviderReferencedProfiles classes.

ReferencedProfile (association) -  This association is implemented as PG_ReferencedProfile association in the InteropProvider.  The instances are dynamically created using instances of  the PG_ProvviderProfileCapabilities  and PG_ProviderReferencedProfiles classes.

SubProfileRequiresProfile (association) - This association is implemented as PG_SubProfileRequiresProfile association in the InteropProvider.  The instances are dynamically created using instances of  the PG_ProvviderProfileCapabilities  and PG_ProviderReferencedProfiles classes.

ElementConformsToProfile (association) - This association is implemented as PG_ElementeComformsToProfile in the InteropProvider.  The instances are dynamically created using instances of  the PG_ProvviderProfileCapabilities  and PG_ProviderReferencedProfiles classes.

Additional Required Classes to implement Element ConformsTo Profile

There are issues with defining a design pattern establishing associations between static and dynamic entities in particular when there are multiple dynamic entities that will contribute instances to the association.  The example we are working with now is the ElementConformsToProfile that relates an element defined by a profile with an instance of registeredProfile that defines the profile for that element.  Today, we expect that registeredProfile will be implemented as static instances (possibly in the future with a provider to protect against errors) and that the key for any given registeredProfile instance is easy to acquire.  However, the element on the other end of this association is generally a dynamic entity and its instance ID may not be known until the first enumerateinstances is performed against the class.  Note that there may be elements that are more static but this is not a given.

This means that instances of the association can only really exist after the provider defining this element is activated in some way so that the instance identification is created. 

However, this is complicated by the fact that one way to find out about such elements is through the association itself so that the starting point for initial queries about this element may well be the an associators request with registeredProfile as the target object which should give back elements that are associated with the target registeredProfile.

In effect, we have a chicken and egg situation.  No associaton until the element is awakened and no element until the associaiton is known.  Since the element is dyanmic, the association cannot be created statically. 

Because of the nature of the relationship between the managed elements (which are often not identified until a provider starts) and the profile instances which are basically static, Pegasus must define some manner in which these associations can be successfully created independent of what the first access is (profile, CIM_Element, or association). This is a characteristic of the issues in defining an association between a dynamic class as one endpoint and a static class as another endpoint.  For the server profile this is handled by implementing two additional classes as follows:

PG_ProviderProfileCapabilities -  This class is used by the Pegasus implementation SMI-S Server Profile to create the instances of and associations between Registered Profiles and Subprofiles, as  the associations between those profile instances and other elements of the Server Profile and the top-level Managed Elements surfaced by the providers to which these capabilities apply. It is implemented in the Pegasus/Interop/Ver20/PG_ServerProfile.mof file.  The class has the following properties:

• unit16 RegisteredProfile - Enum defining the SNIA registered profiles for SMI-s 1.1
• uint16 RegisteredSubprofiles[] - Enum Defining RegisteredSubProfiles for SMI-s 1.1
  string ProfileVersion
• string OtherRegisteredProfile
• string OtherRegisteredOrganization
• string OtherRegisteredSubProfiles[]
• string ConformingElements[]

PG_ProviderReferencedProfiles - This class defines the ReferencedProfile association between profiles and subprofiles implemented by a vendor\'s providers. Where those associations are necessary is specified by the profiles' defining standard (e.g. SNIA\'s SMI-S). The Pegasus Server Profile implementation supplies the ReferencedProfile associations related to the RegisteredProfile instances corresponding to the Server profile. The class includes the following properties:

• uint16 RegisteredProfiles[];
• uint16 DependentProfiles[];
• string RegisteredProfileVersions[];
• string DependentProfileVersions[];
• string OtherRegisteredProfiles[];
• string OtherDependentProfiles[];
• string OtherRegisteredProfileOrganizations[];
• string OtherDependentProfileOrganizations[];

The Software Product and Identity Functions

These are to be considered static and the instances can be created using mof just as the registered profile instances will be created.

Computer System

ComputerSystemProvider stub implementation was modified, in order to make it just usable enough for the requirements of the Server Profile where a more fully-functional ComputerSystemProvider implementation is not present (e.g. Windows, Solaris).

Summary of new mof Classes implemented

The following new mof classes were implemented as part of this task and are defined in Schemas/Pegasus/Interop/Ver20/PG_ServerProfile.mof file. Classes marked with * below do NOT add new capabilities

• PG_ProviderProfileCapabilities  Inherited from  PG_Capabilities
• PG_ProviderReferencedProfiles  Inherited from  PG_Capabilities
• PG_RegisteredProfile*  Inherited from  CIM_RegisteredProfile
• PG_RegisteredSubProfile*  Inherited from  CIM_RegisteredSubProfile
• PG_ReferencedProfile*  Inherited from  CIM_ReferencedProfile
• PG_ElementConformsToProfile*  Inherited from  CIM_ElementConformsToProfile
• PG_SubProfileRequiresProfile*  Inherited from  CIM_SubProfileRequiresProfile
• PG_SoftwareIdentity*  Inherited from  CIM_SoftwareIdentity
• PG_ElementSoftwareIdentity*  Inherited from  CIM_ElementSoftwareIdentity
• PG_ObjectManager*  Inherited from  CIM_ObjectManager
• PG_CommMechanismForManager*  Inherited from  CIM_CommMechanismForManager
• PG_NamespaceInManager*  Inherited from  CIM_NamespaceInManager
• PG_HostedObjectManager*  Inherited from  CIM_HostedService
• PG_HostedAccessPoint*  Inherited from  CIM_HostedAccessPoint
   

These classes have all been defined to be processes in the PG_Interop namespace.

Open Issues

1. Cross namespace associations, their visibility, and the requirements they place on the existence of the classes utilized in the associations in both namespaces.  Pegasus today requires that the complete class tree for both of the reference classes in an association. exist in both namespaces.  Thus, if there is an association between CIM_ObjectManager and CIM_System (i.e. CIM_HostedService), both the CIM_ObjectManager and CIM_System classes MUST exist in both namespaces to allow all of the possible associator requests to be processed (if the result class from an associator class request with result class specified does not exist in the given namespace, the request fails in the repository).  Since the user shhould also be allowed to make requests that involve subclasses of this class (ex. CIM_Computer system subclass of CIM_System) these would also fail.

However, the instance operations would not necessarily fail because the instance provider for the association typically should contain enough information to know that the result class is in another namespace and determine the result class hierarchy from the class repository.  The problem is that class operations do not have the same knowledge of the namespaces associated with references and therefore make the assumption that both references of any association are in the namespace of the target class.

2. DMTF Server Profile - There is currently work proceeding within the DMTF on a server profile and possibly other profiles that MAY NOT be compatible with the SNIA profiles. The potential differences have NOT been explored at this point.

Rationale

This PEP implements a set of specific functionality that is required by all implementors of "providers" in the SNIA environment.  This creates a single implementation of this work that matches the requirements of SNIA for this server to eliminate the duplicated implementations and partial implementations that have been proposed and used by a number of SNIA members who use Pegasus.  This establishes OpenPegasus as a provider infrastructure for SNIA members that includes some of the base functionality required by all members.

Tests and Testing

This work has been largely implemented in the Interop Provider.  It has already passed the SNIA CTP tests.  The tests for the Interop Provider are being expanded to cover the additional functionality. The additional testing will require expanding the Interop tests to a:

1. Test the new classes
2. Implement the basics of the SNIA scripts so that multistep tests can be performed.

Schedule

This work can be integrated into the Pegasus CVS at any time subsequent to the approval of this PEP since the code will be complete at that point.

 

PEP  Milestone	Planned Date	Revised Date	Actual Date	Comments
Functional PEP Approval (this PEP)	Mar 2006	June 2006
Code Available in CVS Branch	Feb 2006	Feb 2006
Request to Arch Team for Merge of Branch	June 2006
Functionality Complete (FC)	June 2006
Certification Test Complete (CTC)	TBD

Discussion

<Additional information from discussions,  reviews, and decisions of the steering committee and architecture team can be recorded here. Information in this section is to help reviewers but MUST also be reflected in the Proposed Solution / Rationale, etc. sections. This section is for information only during the review process.>

--------------------------------------------------------------------------------------------

Comments v 1.4 TO v 1.5

[ (a_dunfey) The objective is to not require ANY Server-profile instances to be populated in the repository or served by the vendor's provider. Instead, what information is required about a specific provider is retrieved through provider registration instances.
¤318]

[ (a_dunfey) Is disabling the feature really what we want? The old way of populating the repository with static instances will continue to work, so in that sense it is a backwards compatible implementation.

RESPONSE: I agree.  Perhaps disabling is really the wrong word.  The implementor must be able to use his own mechanisms in place of this. 
¤321]

[ (a_dunfey) This issue is solved, at least in the short term, by having a compliant, generic stub implementation. It should work for all the platforms that do not have the need for a more fully-featured, platform-specific implementation.
¤367]

[ (a_dunfey) Instead of implementing a Windows-specific stub, the branch currently enhances the generic stub to properly supply the properties required by the SMI-S server profile. This information is gathered from the Pegasus System class.
¤370] ACTION: Implement the windows stub so that we provide at least enough information to support an association between this class and the objectManager (HostedService).  Supporting other information from the manager should be considered by Pegasus for a number of platforms but not part of this PEP.

[ (a_dunfey) If all of the providers use instances of the ProviderProfileCapabilities, there should be no duplicates of the same profile with the same version. Duplicates are handled by the Interop Provider.
¤388] NOTE: There is another issue in that SNIA has NOT placed any requirements on issues of duplicate profiles.  Thus, there is nothing limiting a server from having multiple instances of the Server Registered profile (remember that the properties RegisteredOrganization, RegisteredName, RegisteredVersion are NOT key properties so that syntatically it is legal to create instances with the same information in these fields but different InstanceIDs.

[ (a_dunfey) Created just using the ProviderProfileCapabilities class. The ProviderReferencedProfiles class is only used to create instances of the ReferencedProfiles association and is not required to conform to the SMI-S Server Profile.
¤389] RegisteredProfile - This association is implemented as PG_RegisteredProfile in the InteropProvider.  The instances are dynamically created using instances of  the PG_ProvviderProfileCapabilities  and PG_ProviderReferencedProfiles classes.

[ (a_dunfey) Karl, I can provide these algorithms to you either as comments in the PEP or in a separate email.
¤390] <<<ED Define algorithm>>>

COMMENT: These are included in the new version

[ (a_dunfey) I would suggest putting this before the definitions for the new PG_RegisteredProfile, PG_RegisteredSubProfile, etc. classes. This way the algorithms supplied that explain how instances of those classes are derrived can refer to the properties in the ProviderProfileCapabilities class and a reader who goes from top to bottom will know what those algorithms are talking about.
¤404] Because of the nature of the relationship between the managed elements (which are often not identified until a provider starts) and the profile instances which are basically static, Pegasus must define some manner in which these associations can be successfully created independent of what the first access is (profile, CIM_Element, or association). This is a characteristic of the issues in defining an association between a dynamic class as one endpoint and a static class as another endpoint.  For the server profile this is handled by implementing two additional classes as follows:

[ (a_dunfey) Instances of SoftwareIdentity are also generated from the registration MOF. Instances of the Product class are optional and not provided by the current implementation. As you say, the provider can create them in the static repository or provide them through their own provider.
¤423] These are to be considered static and the instances can be created using mof just as the registered profile instances will be created.

[ (k_schopmeyer) This is not correct since the PG_ElementConformsToProfile is wild carded.
¤442] These classes have all been defined to be processes in the PG_Interop namespace.

[ (a_dunfey) In the current implementation, the CIM_System is 'borrowed' or 'stolen' from the root#cimv2 namespace so we don't have a cross-namespace association issue here. This is a problem for the ElementConformsToProfile class, though. This is currently solved by searching the namespaces that should have the PG_ElementConformsToProfile class but don't and populating those namespaces with the class definition at system startup.
¤444] 1. Cross namespace associations,

---------------------------------------------------------------------------------------------

Comments V 1.3 to V 1.4

[ (a_dunfey) I would agree that there could be some private namespaces. For example, the root/PG_Internal namespace is really for internal server data and shouldn't be advertised to clients. One could argue that its contents should not even be externally visible to clients that stumble across it, but I don't know how we would restrict access to it (aside from the namespace authorization mechanism).
(k_schopmeyer) Or actually not making the namespace externally visible through any of the normal mechanisms. However, this probably would not work since we use the same mechanism for to manipulate namespaces as we do to present them to the outside world and we have no attributes that would allow variable visibility.
¤175] NOTE: The spec says all.  It might be an issue that an implementation would want to keep some namespaces private.  There is no resolution for this now.  In addition to the key properties, the following properties of this class are required.

DISCUSSION ONLY, No Change Proposed.

------------------------------------

[ (a_dunfey) I agree that this could be a potential issue for proxy CIMOMs hosting providers from multiple vendors, but the multi-tenant scenario has not gained any usage in SNIA as far as I can tell. That said, the scenario is being thought about in SNIA and is likely to gain more widespread usage in the future.
(k_schopmeyer) So, the question is should we be protecting against multiple profiles with the same org, name, and version? The SMI-s spoecdoes not disucss this and it is syntatically legal since none of these fields are part of the keys. However, it seems behaviroly wrong and I think that we should disallow this behavior. For that we need a provider to control use of the class since the repository code itself cannot do this. However, I am not going to make an issue of it for Pegasus 2.5.1 since the usage is very limited and error of this type can be found other ways. For me, having the profiles as static instances in 2.5.1 with no protection covers what I wanted to do for this version
¤181] NOTE: The registered profile Class defines a profile in terms of 3 properties (RegisteredOrganization, RegisteredName, RegisteredVersion). Together these define a profile. An example might be snia, server, 1.0.0.  However, the key property is instanceID.  The three other properties are required but not part of the key.  There is nowhere in the SMIS-s specificaiton that I can find any requirement that there be only one instance with a unique organization, name, and version.  With multiple profiles being registered, it seems highly likely that there could be multiple instances registered with the same organization, name, and version unless there were internal protection in the CIM Server.   I assume that the intention of the specification would be only one instance but that should be clarified both for the SMI-s specification and for the implementation.

CONCLUSION:  Nothing special done for this in the current work.

------------------------

[ (a_dunfey) I believe the best long term solution for the namespace of the CIM_System class in the context of the Server profile would be to have the namespace in which it operated be flexible. Right now, the ComputerSystemProvider operates in the root/cimv2 namespace. Vendors that do not need the other ManagedSystem providers for their products may not want to include the root/cimv2 namespace in their WBEM package just to service one class. For those vendors, a flexible solution would be preferable, where the ComputerSystem provider could operate in the interop namespace (or maybe even in a vendor-specific namespace). A vendor could accomplish this now by making their own modifications to Pegasus, but a common, community-supported option would reduce the maintenance burden.
(k_schopmeyer) Agreed. What we don't want to do is to have them be requried to reimplement this class. Actually this probably applies to a bunch of the standard providers and classes. I would think that something like an environment variable defining a concept like 'PEGASUS_DEFAULT_NAMESPACE' which would be set to root/cimv2 for us today but could be modified by a compile environment would cover this issue. At this point I have not handled this since HP is using root/cimv2 for the moment.
¤309] 1. It is implied in the specification that this class exists in the interop namespace.  However, that is not clearly stated.  Further, it is not clear that this is the long term solution we want to support this class in general, not simply as a component of the Interop namespace. 

CONCLUSION: <<<ED TBD>>>

[ (a_dunfey) Presumably we aren't usurping the CIM_HostedSystem association for the exclusive use of the Server profile implementation. I would think that we would subclass HostedSystem, and even then only route requests for that subclass to the interop provider for the root/PG_Interop namespace and root/cimv2 (or whatever namespace the ComputerSystem provider resides in... see my note above).
(k_schopmeyer) Agree. That was an error in my original implementation. We need to do this subclass. I think that this is another one of these things that as a general solution we should be subclassing. That seems to apply to a lot of associations that may have general usage in the environment. Don't let a single provider usurp total responsibility for the association since many providers may have to respond. The problem here is that it is not clear that we have a clear pattern of model usage that will insure this in the future when we get to multi-tennant systems so this one is going to keep popping up.
¤310] 2. The SMI-S spec implies that this is in interop.  Clearly there are some issues here in that this is a very general association that will tie services that may exist in multiple different namespaces to the system class. 

CONCLUSION: <<< This has been implemented as a Subclass>>

------------------

[ (a_dunfey) I can't imagine that this is going to ever be anything but 'on' or 'enabled' or whatever the appropriate value is. I could imagine if the Interop provider had the information to determine whether or not the maximum number of threads or maximum number of client connections had been reached, that the value could be changed to 'stressed' or some such thing. Other than that future possibility, this property does not have much value in my opinion given that if the value was anything besides 'ok', no client could ever retrieve that information anyway.
(k_schopmeyer) Agreed and I have to implment this and a couple of other additional properties that were not in the code to date. I just did not put them into the original code because i was implementing minimal behavior before.
¤321] The Provider does not implement OperationalStatus. 

CONCLUSION: This was implemented.

--------------------

[ (a_dunfey) I don't envision any 'usurpage' issues if the Interop provider is registered for the PG_HostedService class. Vendors shouldn't be implementing providers that service Pegasus-defined (PG_*) classes. Unless, perhaps, the vendor is Proctor & Gamble... but we can cross that bridge when we come to it.
(k_schopmeyer) This all makes the assumption that the Pegasus system is taking responsibility for the PG_* schema. This, however, is an issue that we have never really clarified. I agree that we need to do this in terms of PG_*, not the CIM_* associaitons in general for these associations that can be tied to many objects. That appears to be the way Pegasus will manage this. THe alternative would be to open pegasus so that we could have multiple providers for a single class (or just this in the case of association classes). This is logical and I think that it should be an architectural decision if we do something like this. However, I don't want to introduce extensions like that in 2.5.1 so the PG_Hosted... is the logical solution.
¤358] In any case, to support SMI-S it is logical and simple to include this added association as part of the object manager provider module (InteropProvider).  This should have been done before and will be proposed as a bug fix for 2.5.1.  This is NOT an effective long terms solution since many different services will want to be registered as hosted services.  In fact, I am really uncomfortable with doing this in general for Pegasus 2.5.1 since it usurps this association for a single usage.  However, for SMI-S this is the only usage of teh function so that it can be set up this way as a SNIA_EXTENSIONS function that will provide the capability for SNIA and still allow a more general solution for other users who may chose to implement this differently.

CONCLUSION: <<< TBD>>>

[ (a_dunfey) Why is it responding to HostedService from any namespace? We can't put a routing table entry in for the root/cimv2 and root/PG_InterOp namespace? Are we limited to putting in an entry with the '_wild' namespace?
(k_schopmeyer) Good point. However, I think today there is a limit in that code in the control_provider router that does not allow namespace lists. The way I handled it so far is to allow wild card in the routing table and then limit it in the provider. A couple of alternatives to this would be a) get this class out of the control provider or b) extend the control provider routing definiton to allow namespace lists as opposed to simply namespaces.
¤359] NOTE: At this point, this provider will respond to the HostedService request from any namespace.

CONCLUSION: << TBD>>>

-----------------------

[ (a_dunfey) In all actuality, the simplest solution is to do nothing. Correct me if I'm wrong, but there's nothing stopping a provider from registering for a subclass of ElementConformsToProfile in the root/PG_InterOp namespace. The only information that a provider has to know to provide for that association is the ManagedElement and the RegisteredProfile it is associated to. In order to implement the scheme suggested below, the provider still has to know that information. Also, while the vendor's provider would not have to fully implement all the operations for that class, it still has to do a non-trivial amount of work. I would also argue that the work it does have to do is more error-prone and difficult because it is specific to that class, whereas implementing the association and instance operations for a regular class follows a very well-known pattern.
(k_schopmeyer) I wrote this a month ago. In retrospect, I think that it would be much easier to put the load on the various providers. However, whatever we do here, we should do something general enough so that it suits entities broader than us or even us and SMI-s. This is a general issue, created in part by ourselves because we decided that we wanted a single provider for associations (the association provider) rather than registering the end points as the association providers. In general we should define and document a pattern of usage that covers how we use Pegasus in these cases as well as build something that gets through the CTP tests.
¤461] It would seem that the simplest solution is actually a new provider for this class.  This provider would:

CONCLUSION: <<< Implemented as Subclass with internal pegasus supporting classes>>>

-----------------------

[ (a_dunfey) In regards to the class operations, I don't think it's feasible to require every subclass that could potentially be the result of a cross-namespace association traversal be present in both namespaces. Given an association class X with a reference type of CIM_ManagedElement, every namespace that contained association class X would have to contain all the subclasses of CIM_ManagedElement that exist in every other namespace that also has association class X. This would result in almost every namespace having nearly exact duplicate sets of class definitions. If a client were to do an associators call on 'CIM_ManagedElement' and class X exists in two namespaces and is a result class of that association, what gets returned if the two namespaces have different versions of the same class (say, CIMSchema 2.9 and 2.10.1)?
(k_schopmeyer) I think you hit on what is our real big problem here. THis is not a problem for this work, but general. Since the class operations for associations have NO way to understand anything but the current namespace, they can never respond to anything but the classes in this namespace. This, however, means that we can get error responses for a class level association request and yet still get a good answer back from a provider level because it inherently understands the namespaces it is supposed to be working with. That is the issue I do not know how to solve. I am also very uncomfortable with forcing the full hiearchy of classes to exist in both namespaces and feel that this is completely ERROR PRONE and illogical conception. BUT how do we then handle the association class operations? Today they always return error if the result class does not exist. We may have to live with that as a known limitation for cross-namespace associations.
¤473] However, the instance operations would not necessarily fail because the instance provider for the association typically should contain enough information to know that the result class is in another namespace and determine the result class hierarchy from the class repository.  The problem is that class operations do not have the same knowledge of the namespaces associated with references and therefore make the assumption that both references of any association are in the namespace of the target clas

CONCLUSION: There is still a significant issue over crossnamespace associations.  This has not been solved and at this point we do not see a general solution.  It would appear that unless all subclasses of a particular class are implemented in both namespaces, the class associator operations depending on exactly the parameters provided because the subclasses of the association do not exist in the target namespace.

----------------

[ (a_dunfey) For 2.5.1, I think this is the most feasible thing to do (aka have the vendor's providers do the work)
(k_schopmeyer) I agree but lets talk this one through.
¤480] 1. Subclass the elementConformsToProfile class so that each element provider also includes an instance/association provider for a particular sublclass of elementConformsToProfile so that the first association request will get information back from all elements.  This means that there may be many different providers registered. Note that this introduces some new limitations because of the crossnamespace nature of these associations.  This initial associators request in the interop namespace would do nothing to find providers for the association that were in other namespaces.  Therefore, the associator providers would have to be registered to handle requests both from the interop namespace and the namesapce containing the element that was part of the profile.

CONCLUSION: See implementation of the new classes to provide a dynamic means of solving this problem.

----------

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 9th 2004 by Martin Kirk
Template version: 1.8