Pegasus Project Working Paper

Compiler Extensions to Support Provider Registration

Authors: Denise Eckstein, Karl Schopmeyer

Last Update 2/22/2002 10:31 AM

Document: CompilerExtensionstoSupportProviderRegistration.htm

Revision Status

0.1

KS

Draft for discussion

Introduction

This document defines a set of extensions to the Pegasus Cim Compiler to help with the process of registering providers using MOF and the compiler as the registration tool. The additional functions are felt to be requirements to create an environment in Pegasus Version 2 that is usable for provider installation and registration in running Pegasus systems.

Background

These proposed extensions started with work done by HP to define some rules and possible extensions to the system to help control the input of MOF for provider registration.

We have to assume that provider registration can be done at any time, not simply at build of a new system and must be done when the cimom is running. Further, it is intended that this be done by inputting MOF to the system.

This is one of the characteristics that drives us to create the version of the CIM compiler that is driven from the client interface and can input when the CIMOM is running.

Further extensions revolve around:

• The providers not necessarily knowing what is in the CIMOM when they create their registration MOF.
• Controlling input to reduce the possibility that providers can input incorrect versions of MOF.

This set of extensions goes handin-hand with a set of changes that were just approved by the DMTF:

• Mandatory use of the Version Qualifier in the future, starting with the CIM 2.6 Final release scheduled for March 2002. All classes in the CIM schema must have this qualifier which defines the last CIM Schema version in which the class itself was modified (ex. Version (2.6.0).

The use of the Experimental Qualifier that identifies all classes that are considered experimental and not released. Generally we should Never see the experimental qualifier on any classes in a released version of the CIM MOF and should see it only on classes that change or are added for a preliminary release. All of these classes must be either moved to release or removed from the Schema to allow a schema to move to release status within the DMTF. The String representing the version MUST be in the form of: 

M + "." + N + "." + U

M - The major version in numeric form in which the class was changed. 
N - The minor version in numeric form in which the class was changed. 
U - The update (e.g. errata, patch, ...) in numeric form in which the class was changed.

More information about these changes will be available from the DMTF when CIM version 2.6 final is released.

The Definition of Provider Guidelines

The following guidelines for providers and provider writers help to understand these requirements:

1.) Provider Developer's SHOULD include the definition of all required superclasses in the MOF.
2.) All class definitions MUST include a VERSION qualifier.
3.) Use of the VERSION qualifier string MUST comply with the DMTF guidelines.  In particular, any change that breaks backward compatibility MUST be labeled with a new MAJOR version number.
4.) All included class definitions MUST contain a complete and accurate definition of the specified version of the class.
5.) Provider Developer's SHOULD assume that DMTF qualifiers (version 2.6) are already defined in the namespace.

This MOF Update Utility is a very simple tool that supports a majority of the provider installation senarios.  It handles the straight-forward upgrade cases.  Situations that require more sophisticated Schema manipulation  will require developers to write a customize CIM Client application to perform the necessary checks and schema modifications.  E.g., a customized application could be developed to perform a MAJOR version upgrade.

MOF Enhancements to Support Provider Registration

General changes

1. Extend the compiler to allow class replacement. Thus, the compiler would be able to replace classes as well as install classes under circumstances defined in this document
2. Extend the compiler to allow use through the client interface. The proposed solution is to provide two versions of the compiler. One would be used through the reposiotory interface (as is done today). The second version would use the client interface and would be used only when the CIMServer was running.

Epecific option additions

1. Add a new parameter to the cimmof command line, --experimental, to control handling of the experimental classes and qualifiers.
2. Add a new parameter to the cimmof command line, --version=X.X.X, to allow easy migration of existing MOF files to use versioning.

--Experimental Option

NOTE: References to the Minor version defined below also apply to the update parameter in the Version qualifier.

The --experimental parameter on the command line must be set to allow the CIMMOF to replace an EXPERIMENTAL class definition with either an EXPERIMENTAL or RELEASED class definition (in short to be replaced) if the modification is not a MINOR version  or REVISION update to the class.  If the -- experimental parameter is not defined and any class in a MOF definition is experimental, the entire MOF must be rejected (with no changes to the repository) unless that new class definition represents a MINOR version update or REVISION update as defined by the VERSION qualifier.

This option was originally defined as follows hopefully the definitions above and below match):

A MOF will be rejected if ...

• It would require replacing a class definition with a MAJOR version update.
• If the --experimental parameter IS NOT specified and it would require replacing an EXPERIMENTAL class definition with either an updated EXPERIMENTAL class definition or RELEASED class definition. The justification is that replacing an EXPERIMENTAL with a RELEASED or EXPERIMENTAL class could break other classes ... We wanted to make this action explicit
• It would require replacing a RELEASED class definition with an EXPERIMENTAL class definition.
• It would require replacing a class with an earlier MAJOR version number.
• If the --version parameter IS NOT specified and a class definition does not contain a VERSION qualifier.

A class definition within a MOF will be ignored if ...

• It would result in replacing a class definition with one with an earlier MINOR version number.

An existing class definition will be replaced if ...

• It represents an MINOR version update.
• If the --experimental parameter IS specified and it would require replacing an EXPERIMENTAL class definition with either an updated EXPERIMENTAL class definition or RELEASED class definition.

NOTE: Note the use of the word ignored vs. rejected. The requirement is to reject the entire MOF file under certain circumstances.

This means that somehow the compiler must predetermine if there are any reasons for rejecting the MOF BEFORE it puts any classes into the repository. While this implies a multiplass compiler, we hope that there is some way this can be creatively accomplished without major changes to the compiler (ex. creating a super process that would simply call the compiler with different options for the check phase).

--Version Option

Variations of his option can be use for two things:

• Force the version qualifier to be put on each class.
• Test and insure that the version qualifier is on each class and reject the input if there is any class without the qualifier.

If the options is present with the (x.x.x) the cimmof will add the Version("X.X.X") qualifier to any class that does not have one.

If the option is present without the (x.y.z) it could force the compiler to reject mof that did not have the version qualifier defined for classes.

There is at least one good reason to provide this as a compiler test (probably in addition to having an internal test) – It would be logical to insure that no mof in a mof file was installed if there were classes without the version qualifier.

Note that we have seriously considered proposing that there be a version pragma that would accomplish what is being proposed for the command line. This would be a more logical solution. However, the negative of that proposal today is that a new pragma touches on the DMTF specifications and until and unless we achieved DMTF agreement to the pragma, we would be out of scope with any MOF that had this pragma. It is still a useful concept but we do not want to require it when it is not part of the DMTF standards.

Since starting with version 2.6 (march 2002) all DMTF schemas will have the Version qualifier, the demand for this option has been reduced. The originators would be willing to discuss options or possible deletion of this requirement if it was a severe schedule burden.