Re: CMPI Instance Provider Question.....

Thanks Much guys!

Let me digest all the information you guys gave me and also do some
research/reading.....

I will check back with you guys if I need any help!

Thanks so much.......

Kamal

On Tue, Jan 19, 2010 at 3:34 PM, Kirk Augustin <[email protected]>wrote:

>  Correct.
> If the provider is simply relaying the configuation and/or state of of a
> server, then it is often the operating system, hardware, or diagnostics
> that are the source of the data to be returned.
> But the same sort of programming conditions still apply, where you may need
> to have the provider permanently store some information about instances.
> Such as clients previously requesting something that the provider would
> have to restore if it were to reboot.
> As opposed to properties always dynamically obtained, such as the results
> of a SMART diagnosis on a hard drive.
>
>  ------------------------------
> *From:* "[email protected]" <[email protected]>
> *To:* [email protected]; [email protected]; [email protected]
>
> *Cc:* [email protected]
> *Sent:* Tue, January 19, 2010 2:49:01 PM
>
> *Subject:* 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]<[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/sample/CMPI/InstanceProvider/cmpiInstanceProvider.c
> >
> >direct links for sample code:
> >
> http://cvs.opengroup.org/cgi-bin/viewcvs.cgi/pegasus/src/Providers/sample/CMPI/InstanceProvider/cmpiInstanceProvider.c?rev=HEAD&content-type=text/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
> >
> >
>