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
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
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.
- 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?
Radek Novacek
[1] http://schemas.dmtf.org/wbem/cim-html/2.35.0+/CIM_EthernetPortStatistics.htm...
Hi, Radek -
[...] Regenerating only when the change really happens sounds optimal to me. How often such thing happen? Only on boot? Or any time?
Metrics come and go when a sysadmin reconfigures a PCP installation, to add or remove PMDAs (agents). This is a rare event, let's say a few times per system lifetime.
[...] 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.
OK, will keep that in mind.
[...]
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. [...]
Are our implementations of such standard classes (if any) free to define those in terms of individual PCP data items?
- FChE
On 06/17/2013 04:28 PM, Radek Novacek wrote:
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?
It could be doable as enhancement and it shouldn't brake any compatibility. But I'm not sure if it has any gain.
RR
Hi -
On Mon, Jun 17, 2013 at 05:55:43PM +0200, Roman Rakus wrote:
[...]
If we use PCP bridge directly we're going to lose object-level compatibility with CIM schema. [...]
It could be doable as enhancement and it shouldn't brake any compatibility. But I'm not sure if it has any gain.
As regards to general PCP, the possible gain from is easy access to the hundreds of new metrics made available to the tooling; another is a reduction is code duplication; portability.
Another angle is the ease by which these metrics can be logged & replayed. The proof-of-concept doesn't demonstrate this, but it would not be hard to define e.g. sibling CIM classes that, instead of returning the live data, returns an array of historical data samples from a local archive.
- FChE
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
* Radek Novacek rnovacek@redhat.com [Jun 17. 2013 13:48]:
- 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?
FWIW, OpenWSMAN supports a non-standard enumerate URI of
http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/ClassNames
to work around this omission of the WS-Management standard.
Klaus
openlmi-devel@lists.stg.fedorahosted.org
-
Frank Ch. Eigler -
Klaus Kaempf -
Radek Novacek -
Roman Rakus -
Russell Doty