Re: Review Request 458: prototype CIM<->PCP bridge

[Radek Novacek]

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

Review Request 458: prototype CIM<->PCP bridge

[Frank Ch. 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

Review Request 458: prototype CIM<->PCP bridge

[Radek Novacek]

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...

Review Request 458: prototype CIM<->PCP bridge

[Frank Ch. Eigler]

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

Review Request 458: prototype CIM<->PCP bridge

[Roman Rakus]

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

Review Request 458: prototype CIM<->PCP bridge

[Frank Ch. Eigler]

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

Review Request 458: prototype CIM<->PCP bridge

[Russell Doty]

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
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel

Review Request 458: prototype CIM<->PCP bridge

[Klaus Kaempf]

* Radek Novacek  [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