Abstract:

 The main reason for this PEP is to support the application of "patches" to Pegasus.  As Pegasus is put into production, customers may be asked to install patches.  The patches may have the effect of adding, removing, or replacing (both uplevelling and downlevelling) the objects in the repository.  The current MOF compiler supports adding objects.  However, it does not support removing or replacing objects.

 
 A secondary reason for this PEP is to outline the general usage scenarios of the MOF Compiler.

 
 Note: This PEP was written from the perspective of the patch install/uninstall process on OS/400.  Other platforms will have different scenarios, but it is probable that OS/400 captures most of the scenarios.

 
 Note:  This PEP is a companion to PEP 43: cimmof - Updating Class definitions.  Many of the scenarios covered in this PEP are covered by the new compiler options proposed in PEP 43.  Scenarios in this PEP that are covered by compiler options in PEP 43 will be called out below.

 Scenarios:

 1.0 General Usage

 a) Addition of objects:

 This is already supported by the MOF Compiler.  Any type of CIM object (class, instance, qualifier) may be added to the repository.  PEP 43 describes the option for adding EXPERIMENTAL classes.  Also, developers will be encouraged to use the VERSION quailfier, and follow the versioning recommendations in PEP 43.
 
 

 b) Deletion of objects:

 The MOF Compiler does not have an option to delete objects from the repository based on the objects in a MOF file.  This is a useability issue.  An administrator may wish to test the MOF compiler, or prototype some classes, and then remove those classes.  Forcing the administrator to bring up a CIM client to delete the objects, or manually delete the files in the repository, is not a useable design.

 
 While it would be desireable to handle every possibility in deleting MOF objects from the repository, it may not be possible in the current release.  However, we need to at least solve the 'easy' cases that cover the majority of use cases.  For the other cases,  we can hopefully detect when a delete is not supported and return an error to the user.  Or, at least we can list the unsupported deletions as restrictions in the usage notes for the compiler.
 

 The design principle is that when the administrator does a delete of MOF objects, the intention is to 'clear out' the repository of all related objects, whether they are defined in the MOF itself, or are dependent objects not defined in the MOF.  Also, it is desireable for Pegasus code to assist the administrator by leaving the repository in a consistent state (or at least trying to).
 

 The following is a first pass at the uses cases that should be supported:
 

•  Recursive Class Delete:  If a class is defined in a MOF, deleting that MOF should delete the class and all its sub-classes.
•  This would occur even if the sub-classes were not defined in the MOF being deleted.

 
•  This may cause a provider to be 'disabled' if that classes that it supports are deleted.  However, in the simple 'playing with the MOF compiler' use case there probably is not a provider.  In a 'production' use case, the MOF(s) being deleted would include both the provider and its supported classes.  The usage notes for the MOF compiler may include a warning about providers that may be registered for the classes.

 
•  Instances are discussed below.

 
• Associations and references need to be considered.  It is possible that an association is defined in the MOF to be deleted.  It is also possible that a class to be deleted has an association.  The key discussion point is how to handle dangling classes or associations.  There are Repository APIs (?) to navigate the associations and references.  So, we can tell what the impact of a delete would be.  One possible design would be to add a compiler option to find out "what would happen if I deleted this MOF file".  The compiler could return a message that warns about dangling associations.  Whether we actually allow associations to be deleted is a discussion point.

 

Note:  according to Karl, there is a set of generally good tools to navigate the associations at the class level. Today there probably a few holes in this work but that is what they are trying to sort out with the current association work. We assume that after a delete class, there should be NO dangling classes. the inheritance tree must be complete. Thus, you can only delete from the leaf up. Dangling associations is a major issue, both instances and classes. In effect, part of class deletion should be the deletion of corresponding association classes. In fact, probably these should be deleted before their corresponding referenced classes. To date, none of us (Pegasus, etc.) have really done anything with this issue as far as we can tell. Pegasus does have code to forbid deletion of classes if they are not the leaf and if static instances exist today.
 

• Qualifiers need be considered.  A qualifier may be defined in the MOF that is being deleted.  It may not be feasible from a performance standpoint to scan all the classes looking for ones that use the qualifier.  We may want to block this delete and include this as a restriction in the usage notes.

 

Note:  according to Karl, we do not have any path count or similar thing on qualifiers so just the fact that it is a given MOF does not mean that the qualifier was installed with that MOF. It may have been installed earlier. Generally, it would appear that until the usage of special qualifiers and the addition of new qualifiers by user MOF becomes general, we should probably avoid this question.

 
 
•  Repository Instances:  Instances stored in the repository should be deleted.
•  If they are defined in the MOF then they should be deleted in the repository.

 
•  The instances may have been created by a client after the MOF was compiled.  In this case they should be deleted as part of the recursive class delete, ie. all instances of the classes in the MOF, and all instances of the sub-classes, should be deleted.

 
•  If cimmofl is used, then the repository instances are deleted by using the Repository component.  If cimmof is used, then instance deletes are sent to the Provider registered for the class, if one exists.  The Provider is responsible for the delete in this case.   This is part of the whole issue of behavior in response to cim operations. It is clear that the CIMOM cannot go around deleting classes that have outstanding instances. Today we have no way do distinguish behavior between those providers where deletion of instances makes sense and others where it does not. In any case, if the class were to be deleted, then we cannot get to the provider anyway (at least from the target namespace). It would appear that we must have some more sophisticated behavior here
• static instances do get deleted,
• somehow we need to interact with the provider to determine if we can delete instances,
• when all is in order, delete the class.
 
Note:  Sending the provider DeleteInstance() requests could have some damaging side-effects. For example, the semantics of the DeleteInstance() operation on an instance of CIM_Process could be for the provider to kill the underlying process; thus, killing ALL processes would be an undesirable side-effect of deleting the CIM_Process class. The CIM Ops over HTTP spec. says concerning the DeleteClass() operation, 'If successful, the specified Class (including any subclasses and any instances) MUST have been removed by the CIM Server. The operation MUST fail if any one of these objects cannot be deleted.' However, I don't think there is any general-purpose way for cimmof to know if it's okay or not for it to delete instances. (A spec. change may be in order here too.)

 -tD  Test Delete.  Indicates what would happen if a MOF is deleted, at least as far as can be determined
 -aD Allow Delete.  Does the deletion of objects
 
 

 c) Replacement of objects:

 The MOF Compiler needs the ability to "recompile" a MOF.  An administrator may be testing new class designs, and may wish to recompile the MOF.  The options proposed in PEP 43 cover these scenarios for classes, including changes to the VERSION and EXPERIMENTAL qualifiers of the class.  By using the appropriate option, the administrator can uplevel or downlevel a class.
 

 It is possible that downlevelling a class would break repository instances that depend on properties from the higher version class.    Also, providers registered for the class may be broken.  A discussion point is what can be done by Pegasus code to detect this, or what information can be added to the usage notes.  This should become a separate discussion item and should be scheduled for the arch team.
 

 It is possible that a Provider is registered for a class that has been uplevelled.  Presumably, if the new class followed the versioning guidelines (ie. is backwards compatible) then the Provider would not be broken.
 

 The MOF Compiler currently blocks the replacement of instances.  This should be allowed by the compiler..
 

 A discussion point is whether the MOF compiler should be changed to allow the replacement of qualifiers.
 

 Replacement of instances and qualifiers can be allowed by new compiler options, or the options in PEP 43 can be extended.
 

 2.0 Patches

 Specifically, OS/400 patches have the following characteristics:
 

•  A patch can be marked as superceding (uplevelling) a previous version of the same patch.  OS/400 maintains an installation history of each version of the patch.  The patch developer has access to this history, and needs to take into account the scenarios related to superceded versions of the patch (see below).
•  A patch can call out co-requisite and pre-requisite patches.  Co-requisite patches are installed and uninstalled as a set.  Pre-requisite patches must be on the system before a patch is installed.  OS/400 enforces these dependencies between patches.
•  Patches are usually bundled in 'fix packs' that can be installed by customers at the time of their choosing.  This includes immedidate installation, scheduled installation, or installation at the next system boot. Patches applied at boot time cannot assume that Pegasus is running.  This is a key requirement, ie. it impiles that cimmofl needs to support the scenarios in this PEP.
•  Patches may be uninstalled or downlevelled by customers. It is the responsibility of the patch provider to return the system to the prior state.  This may be the state from the previous version of the patch, or the state prior to installation of any version of the patch (ie. "back to scratch").  The code in the patch is responsible for handling each case.  OS/400 provides facilities so that the code can retrieve the files shipped with each version of the patch.  In this PEP, the files shipped with the patches are the MOF files, and possibly provider libraries.

 The use cases are the following:
 

 Note: "supported schema classes" below refers to classes that are listed in the registration as supported by the provider.
 
 

 a) Install a new provider and supported schema classes:

 This is the simple case of registering a new provider, compiling the schema class it supports, and dropping the provider library onto the system.
 
 

 b) Uplevel (replace with new version) an existing provider and its supported schema classes.

The patch install code would do a "recompile" to replace the provider registration instances and the supported schema classes.  This would most likely involve a minor version upgrade.  PEP 43 proposes that minor version upgrades be allowed for classes.  This should be extended to allow for the upgrade of instances.
 

 There would also likely be a new provider library to be placed on the system.
 
 

 c) Downlevel (replace with previous version) an existing provider and its supported schema classes

 The patch install code would probably do a "recompile" to replace the provider registration instances and the supported schema classes.  This would most likely involve a minor version downgrade.  The options proposed in PEP 43 cover this for classes.  This should be extended to allow for the downgrade of instances.
 

 It is possible that repository instances of the supported schema classes may be broken by the downlevelling.  However, since providers typically do not store instances in the repository, this is not a major consideration.  Also, repository instances tend to be static (ie. installed with the patch, and never changed by clients).  The patch install code may simply delete the MOF that defined the static instances, and compile the previous version of the MOF.
 

 The patch install code would likely replace the provider library with the previous version.
 
 

 d) Uninstall (remove) provider and its supported schema classes

 The patch uninstall code would delete the provider registration MOF and the MOF for the supported schema classes.  As described in the delete scenario above, this would remove the supported schema class, its subclasses, and all the instances.  It would also remove the provider registration instances.
 

 The patch install code would likely remove the provider library.