CIM_SettingData, usage patterns, etc.

Jan Safranek jsafrane at redhat.com
Tue Mar 5 08:34:55 UTC 2013


On 03/05/2013 12:58 AM, John Dennis wrote:
> Several related questions here:
> 
> As a CIM newbie I've been able to find the specs, the schemas, the
> tutorials, existing implementations, etc. Many of these resources have
> tremendous detail but usually it's on entities in isolation (e.g. the
> classes) or discussions at a very abstract level with no practical
> examples. What I've had a heck of a time finding is "patterns of usage".
> In other words given the existing model and it's available classes how
> do you assemble the disparate pieces according to best practice to
> arrive at a solution that is consistent with how CIM experts expect CIM
> to be used? I'm wondering if there are resources that discuss the
> "practical how-to of CIM modeling", if so could someone point me that
> information?

There is no such thing :). It probably differs from profile to profile.
SMI-S (the storage standard) has pretty consistent usage of capabilities
and settings, see below.


> Here is a good example of where I have a hole in my understanding.
> 
> I need to model a service. That service has configuration parameters. My
> understanding is I need to do the following:
> 
> * Derive a class from CIM_Service (or one if it's subclasses)
> 
> * Derive a class from CIM_SettingData that encapsulates the
> configuration parameters for the service.
> 
> * Derive a class from CIM_Capabilities that enumerates what can be set
> in the matching SettingData class.
> 
> The service will instantiate a SettingData instance and set an
> association between the service and SettingData, this represents the
> current configuration parameters. Is this correct?

Yes, you got it right.

> Now lets say someone wants to modify the configuration parameters for
> the service. How do they do it? It seems as if one needs to instantiate
> a SettingData instance with the desired parameters and pass that to the
> service. Is that correct?

Yes.

> If so it would seem there are two ways to accomplish that.
> 
> 1) Define a method on the service which accepts a reference to a
> SettingData instance.
> 
>   a. Does the provider examine the SettingData and only update
>      the non-null parameters?
> 
>   b. Does the provider replace the existing association between
>      the service and it's SettingData with the new reference?

Partly. For example in storage, several services have method named
CreateOrModify<something> (
     CIM_<something>Setting REF Goal,
     CIM_ManagedElement Element,
     ...)

This method creates the Element, if it is Null, or modifies the Element
if it already exists.

Some services have separate Create<something> and Modify<something>.

In both cases, these methods *copy* the SettingData and associate the
copy with the created/modified element. Thus, the application can re-use
the SettingData for next CreateOrModify / Create / Modify call.

I have briefly described this in my storage provider documentation:
http://jsafrane.fedorapeople.org/openlmi-storage/api/0.5.0/usage-generic.html
 (feedback welcome, is it confusing? how to make it better?)

There are several variants of this concept in the storage standard, for
example sometimes the SettingData is passed as reference (i.e. there
must be appropriate SettingData instance on the server) and sometimes as
EmbeddedInstance (i.e. as string with encoded instance, thus the
instance is on the *client*) and also the Capabilities classes have some
variants.

But this applies to storage. I don't know what the other profiles define
Capabilities/SettingData/Service usage.

I hope it helps.

Jan


More information about the openlmi-devel mailing list