On Mon, 2013-06-17 at 16:28 +0200, Radek Novacek wrote:
Hi, Frank,
On Mon 17 of Jun 2013 10:00:04 Frank Ch. Eigler wrote:
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.
Regenerating only when the change really happens sounds optimal to me. How often such thing happen? Only on boot? Or any time?
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?
Yes, I meant to have something like LMI_PcpConfigurationService with method Reconfigure. It should be doable but I really like the first approach (regenerate when something changes) more.
- 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?
This question was aimed to the rest of openlmi team. I really don't know if we're going to target WS-Man. If so, we should consider it when modeling stuff.
WS-Man is, at most, a secondary target. As I understand it, the rest of the system would work with WS-Man, but the PCP based performance indicators wouldn't?
- 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.
This sound reasonable, however we won't be following the CIM modeling. For network statistics there is standard CIM class CIM_EthernetPortStatistics [1] that provides compatible access to network port statistics.
If we use PCP bridge directly we're going to lose object-level compatibility with CIM schema. I don't know how much do we care about it. tsmetana, jsafrane
- what do you think?
We are using the CIM models as a starting point; as a general guideline, we should reference the CIM models unless we have a reason not to. I'm not especially worried about object-level compatibility in the performance monitoring space - outside of the network, I/O, and CPU monitoring we have in those providers.
Radek Novacek
[1] http://schemas.dmtf.org/wbem/cim-html/2.35.0+/CIM_EthernetPortStatistics.htm...
openlmi-devel mailing list openlmi-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel