Hi, Radek -
[...]
- "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?
- 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?
- 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