pcp
[Top] [All Lists]

Re: Local context vs dynamic namespace

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: Local context vs dynamic namespace
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Wed, 14 Apr 2010 08:55:38 +1000
Cc: pcp <pcp@xxxxxxxxxxx>
In-reply-to: <378220262.614601271196142712.JavaMail.root@xxxxxxxxxxxxxxxxxx>
References: <378220262.614601271196142712.JavaMail.root@xxxxxxxxxxxxxxxxxx>
Reply-to: kenj@xxxxxxxxxxxxxxxx
On Wed, 2010-04-14 at 08:02 +1000, Nathan Scott wrote:

> I was thinking something along those lines, but more system-wide than
> user specific.  If we had a /etc/pcp.local.d/ directory, we could have
> the agent Install scripts drop a file in there in __pmSpecLocalPMDA
> format for dso agents, and we could ship a kernel and mmv one in there
> by default.
> 
> Infiniband rpm installs could then drop one in there, and the cluster
> PMDA would be simplified a bit.
> 
> We could also do away completely with dsotab in libpcp then... and
> fill that in "on the fly" based on contents of that directory.

No real issue with this, but a few comments.

1. By "drop a file" I presume you're thinking one file per pmda that
wants to play, and then "somewhere" in libpcp I process all of the files
in the magic directory.  This means update is file replacement, rather
than the edit and update a common file model that is much more error
prone.

2. Could the file live below $PCP_VAR_DIR?  This would avoid adding
another variable to /etc/pcp.conf.  I'd suggest
$PCP_VAR_DIR/config/local_pmdas or $PCP_VAR_DIR/pmdas/local_pmdas.

3. Making the compile-time build of dsotbl go away is probably a good
idea.

4. Should we retire the $PMDA_LOCAL_PROC and $PMDA_LOCAL_SAMPLE controls
that influence when the proc and sample metrics might be available for
PM_CONTEXT_LOCAL?  I think they are passed their use-by date, so would
not worry if they were quietly forgotten about.

5. A lot cleaner than all of this would be an extended pmcd.conf format
that included a "pick me for PM_CONTEXT_LOCAL" flag ... there is space
to do that at the end of the dso line (no arguments for dsos). This
would be
        - system wide
        - at the discretion of the pmda install script
        - atomic with pmda install/remove
        - no environment variables

6. With all of this, it is not clear how useful the CLEAR operation to
__pmLocalPMDA will be ... I can still see a remote case for needing ADD
and DEL, but in some ways the need for all of __pmLocalPMDA and
__pmSpecLocalPMDA would almost go away if the PMDAs for PM_CONTEXT_LOCAL
was driven off pmcd.conf ... except for your original requirement 8^(>
to be able to use metrics from a PMDA when pmcd was not running ... if
pmcd is not running then perhaps the PMDAs have not been Installed and
pmcd.conf contains no reference to the PMDAs of interest.

I think I've argued around a full circle so, probably scrap 5. and 6.
and go with the rest of the suggestion.

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