Pegasus Project Working Paper

Unsupported Classes in the Repository

Last Update Friday, October 19, 2001 08:07 AM

Revision Status

Introduction

The instance operation routing algorithms for the Pegasus platform treats the instance repository (if it is activated) as the provider of last result so that any instance operation request (create, enumerate, modify, etc.) for which there is not a specific provider defined (via the provider qualifier today) is routed to the instance repository for handling.  Thus, if a create instance for any class which does not have a provider defined is received it is routed to the instance repository or if an enumerate instance request arrives for a class that does not have a provider defined, the request is passed to the instance repository handler and the response provided according to any instance information for the target class that might be in the instance repository.

At the same time, we typically load all of the classes of all or most of the DMTF CIM Schemas and then add the classes required for our implementation and/or environment. This means that typically there are a significant number of classes in the class repository which are not  supported by providers.

Pegasus users have identified this as a potential problem for several reasons:

1. Existence of a class in the schema does not imply that the class is  implemented/instrumented. 
2. Clients can not differentiate implemented classes from unimplemented  classes. 
3. Browsers and other tools will produce a list of all classes giving no clue to the user if there is any provider support other than the provider qualifier.
4. CIM Clients can create instances for classes that are not supported and this instance information will be placed in the instance repository with no known strategy for ever understanding that it is worthless information.
5. A client may create an instance of the class, expecting an underlying resource to be affected (e.g., a client may create an instance of a User class expecting the user to get added).  
6. A client may see an instance created by another client and believe it  reflects the state of an underlying resource

It appears then that there is a requirement to be able to separate classes that are supported in some way by the CIMOM and providers from those that are not.  At the same time, this is not as simple as just using the provider qualifier (or in the future the provider registration) because there may be valid reasons for using the instance repository for storage of instance information about selected classes.

For these reasons, it appears that the repository should be explicitly registered for the classes it serves rather than the current situation of letting it act as default.

Limiting Access/Modification for Static Information

A related issue is that there is fundamentally a difference between a "provider" manipulating instances that are served by the repository and clients manipulating those instances.  That is, the instances generally relate to the state of some underlying managed resource.  The resource owner knows that state and can accurately supply the instance information to be kept in the repository.  Clients, on the other hand, want to retrieve this information rather than supply it.  Those clients should not generally be trusted to manipulate the instances in the repository.

Microsoft addresses this issue by defining "push providers" (as opposed to the "pull providers" like what Pegasus currently has).  

HP has  proposed that we devise a mechanism for Pegasus that allows static instances to be created/manipulated by the resource owner while allowing only read access by clients. We could be more general than this if we create access control at the class level so that, for example, the resource owner could dictate the access by other potential.  Thus the resource owner could dictate read-only access by other users.

Somewhere in there there is a logical ground.  We probably do need to limit the ability to change on some basis.  However, I suggest that we can try to do that as part of the access control mechanisms we are planning to design (which is another use case for class level access control) rather than building a special mechanism.  

Therefore, I propose that we move this discussion to the access control discussion and in this note consider primarily the algorithms for routing, especially those dealing with the instance repository.

Proposal to Establish ownership of Classes

Note: Much of this discussion bears a strong relationship to ideas that would come from ownership of entities within the CIMOM, Primarily the classes.  However, until we resolve the access control definitions (authorization rules) we do not know what we can do with ownership technologies.

Proposal to Modify Operation of CIMOM Routing

We therefore propose that what we want to do is to force the identification of not only classes with valid providers (that would be identified through the provider qualifier or provider registration) but also to identify those classes for which the instance repository is to be the "provider".  In essence we are establishing ownership of classes. With the provider qualifier this is a simple change since there is no concept of ownership and involves:

1. Change the CIMOM routing so that there is no default provider.  Any instance operations against instances of classes for which there is no provider will receive an error return.  Any class for which the instance repository is to be used must have the provider qualifier set to "Repository".
2. At the same time, this then requires that the provider qualifier be supplied for all classes for which we are interested in using the instance repository. Since today setting the provider qualifier is a very manual activity (adding a qualifier to the class definition)  with no real defined provider registration tools. We simply set the qualifier for classes that will use the repository as part of the general process of setting the provider qualifier. Thus a provider that wanted to register itself would add the provider qualifier to classes that were to be routed directly to the provider and also set the provider qualifier to "repository" for classes that it wished to manipulate through the instance repository.

This becomes more complex when we move to using provider registration as the tool for determining the provider associated with a class.  The provider class today lists the classes associated with a particular provider so that these classes are "registered" for the provider when an instance of the provider class in installed in the CIMOM.  However, to date, we have assumed that the classes for which we are registering are to be associated with the provider being registered.  However, we may want to register classes against the "repository" provider in addition to registering classes against the provider being registered. Thus the process of registering a provider may associated certain classes with this provider but also associate certain classes with the instance repository.  Further, when the provider is de-registered, we would assume that these classes in the instance repository might also be de-registered.

NOTE: At this point I am just preparing to look  through Christinas definitions (an interop proposal) for provider registration to determine if we need to add something.

---END OF DOCUMENT--