Sending to openlmi-devel@ to have wider audience then on -review list.
Thanks for providing this proof of concept, I think having access to pcp metrics would be very valueble for us. But I'm not sure that the approach of having the classes dynamically created runtime is the right way to go. Here goes some notes:
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). I think we should at least have CIM API for regenerating this class list.
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?
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.
Radek Novacek
On Sat 15 of Jun 2013 3:41:24 Frank Eigler wrote:
This is an automatically generated e-mail. To reply, visit: http://reviewboard-openlmi.rhcloud.com/r/458/
Review request for OpenLMI Developers.
Repository: openlmi-providers
Description
prototype CIM<->PCP (performance co-pilot) bridge, for review/comment
Diffs
src/pcp/PCP_Metric.mof PRE-CREATION src/pcp/PCP_Metric_PMNS.mof PRE-CREATION src/pcp/PCP_Metric_PMNS.reg PRE-CREATION src/pcp/PCP_pmns2mofreg.sh PRE-CREATION src/pcp/README PRE-CREATION src/pcp/pcp-metric.py PRE-CREATION
Diff: http://reviewboard-openlmi.rhcloud.com/r/458/diff/
Testing
smoke-testing via YAWN web gui
Thanks,
Frank Eigler