Date: Wed, 14 Apr 2010 09:23:58 +1000 (EST)
From: Nathan Scott <nathans@aconex.com>
To: kenj@internode.on.net
Cc: pcp <pcp@oss.sgi.com>
Message-ID: <1419860990.620491271201038915.JavaMail.root@mail-au.aconex.com>
In-Reply-To: <1271199338.24244.278.camel@bozo.localdomain>
Subject: Re: Local context vs dynamic namespace
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


----- "Ken McDonell" <kenj@internode.on.net> wrote:

> On Wed, 2010-04-14 at 08:02 +1000, Nathan Scott wrote:
> 
> 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

Right, that was what I was thinking.

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

Right.  Someday, pmcd could perhaps take a leaf out of this book,
but way beyond scope here.

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

I'd be happy with that too, yep.

> 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

Mmm, yes, nice idea - do we even need to extend the format?  Just say
any dso pmda listed in pmcd.conf is auto-loaded for local context?
With the clear/add/del a programmer can still fine tune their needs,
if they really just want particular PMDAs for a specialised tool.

This all means you have to parse pmcd.conf in libpcp, which is a bit
more involved perhaps than walking a directory and using the existing
(-K) parser code ... but, you choose, I'd be happy with either way.

cheers.

-- 
Nathan