RE: CMPI Instance Provider Question.....

Element level embedded providers don't necessarily have any sort of
database in back of them.   Rather they rely on accessing information
from the underlying device implementation via internal API's.

 

On the other-hand, your database assumption is generally true for proxy
providers.

 

G

 

From: Yoder, Alan [mailto:[email protected]] 
Sent: Tuesday, January 19, 2010 3:01 PM
To: Kirk Augustin; kamal jeera
Cc: [email protected]
Subject: RE: CMPI Instance Provider Question.....

 

If a provider were a way of executing arbitrary relational queries
against a relational back-end database, all would be well.

But it's not. It's a way of transforming some of the information from
what are best thought of as numerous flat-file back-end databases into a
network-model database that is built and delivered piecewise on demand.
This has no real hope of changing the current reality, which is that....

All real world general-purpose management clients that I've heard of
build a database (usually using a relational DB) of the results of a
complete system scan, at least once a week. In between, they rely on
indications and queries to fill in changes to the underlying world being
managed. They have to do this so that arbitrary relational queries
against a back-end database are possible. Once you factor in the network
latencies involved in all the CIMOMs and providers talking to each
other, having your own "back-end database" is the only way to
efficiently answer questions like "how many GB worth of LUNs are
connected to server X?"

Alan

Alan G. Yoder, MSEE, Ph.D.
Office of the CTO
NetApp



-----Original Message-----
From: Kirk Augustin [mailto:[email protected]]
Sent: Tue 1/19/2010 10:38 AM
To: kamal jeera
Cc: [email protected]
Subject: Re: CMPI Instance Provider Question.....

Just an opinion, so ask others as well.
But I would not store anything that you can't get from the actual
database.
So what I would do is write out a simple flat sequential file of all the
instances.
With each instance, save whatever you would need in order to get the
rest from the actual database, such as the database record key values.
And only write out properties to the file, that you can not get from the
actual database, such as namespace, class name, etc.
If you duplicate anything from the database, you run the risk of having
stale data and not knowing it.

It will be a little confusing, because there will be 3 catagories of
values:

A. Those relative only to CIM. 
Such as the namespace, class name, etc.

B. Those relative to CIM and the database.
Instances and properties that show up in the schema or CIM queries but
you get from the database.

C. And those relative only to the database.
The keys you need to access a record from the database, but CIM does not
need to know about.

You only need to store A and C in your flat file, in order to get B when
necessary.

I hope that makes sense.




________________________________
From: kamal jeera <[email protected]>
To: Kirk Augustin <[email protected]>
Cc: [email protected]
Sent: Tue, January 19, 2010 10:13:18 AM
Subject: Re: CMPI Instance Provider Question.....


thanks much for reply...

Is there any sample code for that?

In my case, I have database but it is read only.  System creates the
records and saves it in database.
My provider will go after that database and get the data and then should
update the class properties.

In that above scenerio, what the best design? any suggestion? should I
put the data in a file once I got back from database?

As first step,  Instead of going after the database, I thoghout give
static values to the class properties. that is why I was going throught
that example....

Any suggestions on those lines are really helpful....

thanks much for your time.....I am bit new to this..

Best,
Kamal


 
On Mon, Jan 18, 2010 at 12:18 PM, Kirk Augustin
<[email protected]> wrote:

The sample code is a little simplistic.
>It is best to think of the original CIM model, which is that the
provider is a front end for some sort of external database or other
enity.
>That is where the existence of instances is actually to be kept.
>The provider is best thought of as transient, and not the real storage.
>Just a go-between.
>So the provider should not really matter what representation it uses,
because it gets the actual existence and data from elsewhere.
>If you don't really have a database behind your provider, you still
need to create some sort of non-volitile storage, like write data needed
to recreate instances off to a file.
>Providers are not persistant, so an array is not sufficient permanent
storage.
>
>As far as namespace, I don't see how that is relevant. 
>You expose whatever instances you want.
>The provider only knows about one namespace normally, unless I supposes
you could registered the same provider in more than one namespace, or a
provider can act as a client and go off to other namespaces to gather
data.
>
>
>
>
________________________________
From: kamal jeera <[email protected]>
>To: [email protected]
>Sent: Mon, January 18, 2010 11:44:53 AM
>Subject: CMPI Instance Provider Question.....
>
>
>
>
>Hi fellows,
>
>Got quick question.....
>
>I was going through sample CMPI instance provider, links below:
>
>link:
http://cvs.opengroup.org/cgi-bin/viewcvs.cgi/pegasus/src/Providers/sampl
e/CMPI/InstanceProvider/cmpiInstanceProvider.c
>
>direct links for sample code:
>http://cvs.opengroup.org/cgi-bin/viewcvs.cgi/pegasus/src/Providers/samp
le/CMPI/InstanceProvider/cmpiInstanceProvider.c?rev=HEAD&content-type=te
xt/vnd.viewcvs-markup
>
>
>You can see that during initialize(), he creates 3 instance.  He
creates them root/SampleProvider namespace +  he creates array to hold
the instances created
>
>is that a normal process?  meaning you have to create instances in an
array in a namespace? 
>
>I got this question, becasue during enuminstance or getInstance [see
the above sample],  I need to go through all instances in namespace
right.  so unless I have an array like in the above sample, I just dont
know how to traverse that namespace.
>
>Any thoughts?
>
> 
>thanks much....
>kamal
>
>