Pegasus Enhancement Proposal (PEP)

PEP #: 313

PEP Type: Functional

Title: PEP#313 - Pluggable Provider Managers

Version: 1.2

Created: 25th April 2008

Authors: Norm Paxton, Bart Whiteley

Status: Approved

Version History:

Abstract: Enhance Provider Manager Service to accept pluggable Provider Managers

Definition of the Problem

As OpenPegasus currently exists, it only supports providers written against the C++(OpenPegasus proprietary), CMPI (including CIMPLE), and JMPI interfaces. it is very difficult to add support for providers written in additional interfaces to support additional languages, and that development must be integrated into Pegasus build process [1]. This limits OpenPegasus from being able to embrace interfaces for additional languages that may greatly simplify the task of writing providers.

There is a desire to make various components of Pegasus more loosely coupled and pluggable. It is anticipated that the enhancement described in this PEP will be the first of several such efforts. Other candidates for future refactors include the repository, indication handlers, protocol adapters, and authentication modules.

Proposed Solution

The proposal is to enhance current code to load provider managers from a config-specified, well-known directory, rather than from a static list in code that must be modified to add a new type. This directory will be enumerated and found files will be “tested” to see if they are ProviderManagers (if they are properly named, and provide the required entry-points). If so, their information will be stored for later lookup so as to not require a rescan of the directory. When a CIM operation request is received, the lookup table will be queried to find which ProviderManager provides the specified interface type and version. The path to the ProviderManager will then be passed to the cimprovagt via the ProviderIDContainer, so that cimprovagt can load the appropriate ProviderManager.

Exception is made for DefaultC++ProviderManager: It gets added to the lookup table for verifying interface types and versions, but is handled separately in BasicProviderManagerRouter::_getProviderManager().

The CMPI and JMPI provider interfaces will be modified to use the new pluggable mechanism.

As the cimserver enumerates the directory containing ProviderManagers, Any library not named "lib*ProviderManager.so" (in the case of Unix) will be skipped. Libraries matching "lib*ProviderManager.so" will be loaded and tested to see if their Pegasus version matches the version of the cimserver. If the versions do not match, the library will be skipped and an error will be logged. Nothing but an exact version match will be tolerated, since the interfaces required to build a ProviderManager are not frozen or part of the public SDK.

Care should be taken to ensure that only the system super user has write permission on the directory containing the ProviderManagers.

Following is a list of necessary code modifications:

• Add new class: ProviderManagerPluginMap, implemented as a singleton that will scan the ProviderManagers directory and build the lookup table (map)

  • Modify appropriate Makefile

  • Add a unit test for the ProviderManagerPluginMap

• Have a new config item specifying the default ProviderManager directory (this supports multiple OS's)

  • ConfigManager.cpp

  • FileSystemPropertyOwner.cpp

  • FileSystemPropertyOwner.h

  • FixedPropertyTable*.h

• Modify the makefile/installation scripts to put the Provider Managers plugins into that directory, tests, etc.

  • Makefile.Release

• Add member variable to ProviderIDContainer for full path to provider manager, and modify the serialization / de-serialization of ProviderIDContainer accordingly.

  • OperationContextInternal

  • CIMMessageSerializer

  • CIMMessageDeserializer

• In ProviderRegistrationProvider: Rather than using a static list of provider interface types (local to this file), query the ProviderManagerPluginMap for valid provider interface type and version.

• In ProviderRegistrationManager: Rather than using a static list of provider interface types (local to this file), query the ProviderManagerPluginMap for valid provider interface type and version.

• In ProviderManagerService: When a CIM operation is received, get the provider manager path from the ProviderManagerPluginMap and put into ProviderIDContainer

• In BasicProviderManagerRouter: Rather than using a static list of provider interface types (local to this file), get the full path to the ProviderManager shared object from the ProviderIDContainer.

• In Current ProviderManagers (CMPI, JMPI): Add necessary entry points for ProviderManagerPluginMap to query supported interface types and versions.

The following changes will be made for PEP#308:

providerManagerDir

• Description: Specifies the names of the directory that contains ProviderManager plugin libraries
• Recommended Default Value (Development Build): /usr/lib/Pegasus/providerManagers
• Recommended Default Value (Release Build): /usr/lib/Pegasus/providerManagers
• Recommend To Be Fixed/Hidden (Development Build): No/No
• Recommend To Be Fixed/Hidden (Release Build): Yes
• Dynamic?: No
• Considerations: Should be a dedicated directory to minimize inspection of non-applicable files. Additionally, since all calls to the providers go through the provider managers, the same care should be taken with regards to security for provider manager directory, as for provider directories.
• Source Configuration File: Pegasus/Config/FileSystemPropertyOwner.cpp

Rationale

New provider managers can be vendor-deployed and vendor-replaceable without the need to patch Pegasus code [1]. This also isolates the list of provider interface types and versions to a single location, rather than 4 separate files as is currently the case.

Schedule

This enhancement is scheduled for inclusion in Pegasus 2.8.0.

Discussion

[1] While the ultimate goal is a stand-alone plugin provider manager that can ship in its own rpm and be an add-on to OpenPegasus, it is acknowledged that ProviderManagers make considerable use of non-frozen interfaces in the Common library. One proposed solution to this is a “vendor” SDK, separate from the public SDK, that includes non-frozen interfaces beyond the normal SDK, and does not promise forward compatibility. Developers of extension SDK's, that do not get submitted back to OpenPegasus, would need to understand in advance that future versions of Pegasus may require enhancements to their extensions.

While it may seem like this PEP proposes a significant change to Pegasus behavior, it is really quite minimal. Today the Provider Managers are already in separate shared libraries, and are dynamically loaded as needed. There is a hard-coded "if, else if" block of string compares used to determine which ProviderManager to load. This PEP proposes to dynamically build the mapping of provider types and interface versions to ProviderManager shared libraries, instead of the hard-coded table that is used today. This PEP does not propose to change the interaction between cimserver or cimprovagt and the ProviderManagers once loaded, nor does it propose to define this interaction.

It is anticipated that the performance impact of this enhancement will be negligible

For systems that require static linking, the same solutions employed to enable static linking of providers (see PEP 308) will need to be used for ProviderManagers and other future components that are made more open and pluggable.

Copyright (c) 2008 Novell, Inc.; 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