pcp
[Top] [All Lists]

Re: Device Mapper (dm) PMDA

To: Paul Evans <pevans@xxxxxxxxxx>
Subject: Re: Device Mapper (dm) PMDA
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sun, 29 Mar 2015 20:37:29 -0400 (EDT)
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <5515A322.4080000@xxxxxxxxxx>
References: <5515A322.4080000@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: wQX/0QJPqVFwbAexftNJjYB7qEJQ4Q==
Thread-topic: Device Mapper (dm) PMDA
Hi Paul,

----- Original Message -----
> Hi,
> 
> Due to the feedback gained from the PCP mailing list with regards to the
> dm-thin PMDA, I have undertaken thetask of merging both dm-cache and
> dm-thin PMDA's into pmdadm (device-mapper)for review/inclusion.
> 
> This PMDA consolidates the functionalities of both the PMDA's whilst reusing
> the PMID originally given to the dm-cache PMDA. As before both of these
> PMDA's requirethe dmestup tool's status switch for their respect targets in
> order tocollect data for their metrics.
> 

Thanks!  One little issue I see here is that the metric names change.  This
is problematic for anyone using the existing dmcache metrics - for example,
see src/pcp/dmcache/pcp-dmcache.py.  Other, kinda-related issues crop up if
we make these kinds of changes - tools like pmlogrewrite(1) have had to be
created to deal with transitions of names and other metric metadata.

However, there's an easier way to tackle this - see attached patch, which is
using the pmdaproc.sh feature to allow multiple top-level namespace entries
for one PMDA, and they don't have to match the PMDA name (in our case, we'll
want dmcache.* and probably dmthin.*, rather than dm.*).

(the patch is incomplete, just showing the start of what's needed - do you
want to finish it off?  else just chuck it back over the fence to me and I
can take it on).

cheers.

--
Nathan

Attachment: dm-names.patch
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>