Review Request 458: prototype CIM<->PCP bridge

Frank Ch. Eigler fche at redhat.com
Mon Jun 17 14:00:04 UTC 2013


Hi, Radek -

> [...]
> 1) "PCP metrics can come and go" - the question is when the classes should be 
> regenerated? First creation can be done on package installation. But what to 
> do if one want to regenerate later (possible remotely). 

It could be done on demand, driven automatically from the PCP side (as
those services are notified when new metric hierarchies come and go),
or from something as simple as a cron job rerunning the generation and
registration scripts.

> I think we should at least have CIM API for regenerating this class
> list.

You mean a MOF class method of some sort?  Are those ever run with
sufficient privilege to reconfigure the CIM server?


> 2) What about WS-Man? This model won't work with WS-Man, because WS-Man 
> doesn't have EnumerateClasses. Do we care about WS-Man?

(I'm sorry, I don't know what this implies.)  Is there some other enumeration
function I could add into the proof-of-concept to let WS-Man get at the data?


> 3) I would rather see some internal logic instead of having direct 1:1 export 
> of pcp metrics. E.g. association between network.interface.* metric and CIM 
> representation of given network interface (IPNetworkConnection). I think we 
> should follow CIM modelling more closely.

The way I've been thinking about this is that this kind of domain
knowledge could be encoded into those CIM models rather than into the
generic PCP bridge.  For example, would it be possible for the OpenLMI
IPNetworkConnection code to redirect some statistics inquiries to the
PCP_Metric_XXX it knows about.


- FChE


More information about the openlmi-devel mailing list