Last Update Friday, October 19, 2001 08:07 AM
Revision Status
Revision | Date | Author(s) | Reason |
1.0 | 15 October 2001 | K. Schopmeyer | Original |
2.0 | 19 October 2001 | KS | Comments from Denise. Distribute this version to Pegasus for Comment |
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:
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.
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.
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.
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:
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--