pcp
[Top] [All Lists]

Re: [pcp] patch/RFC - install global derived metrics dir and configs

To: Mark Goodwin <mgoodwin@xxxxxxxxxx>, pcp@xxxxxxxxxxx
Subject: Re: [pcp] patch/RFC - install global derived metrics dir and configs
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Fri, 11 Mar 2016 08:56:56 +1100
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <56E1E74A.4070402@xxxxxxxxxx>
References: <56DD0704.3000800@xxxxxxxxxx> <1562841800.28672134.1457396071684.JavaMail.zimbra@xxxxxxxxxx> <56DF6209.9040905@xxxxxxxxxx> <302778934.28941768.1457480717032.JavaMail.zimbra@xxxxxxxxxx> <56DF7933.1030005@xxxxxxxxxx> <y0m8u1rd2ci.fsf@xxxxxxxx> <56E0AC6B.2030908@xxxxxxxxxx> <56E1D78E.5010700@xxxxxxxxxxxxxxxx> <56E1E74A.4070402@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
On 11/03/16 08:29, Mark Goodwin wrote:
...
yes, but 2. and 4. are also available, as follows :

2.
PCP_DERIVED_CONFIG=/var/lib/pcp/config/derived:/my/own/private:/some/where/else


4. PCP_DERIVED_CONFIG=""

The current patchset actually checks access($PCP_CONFIG_DERIVED, F_OK)
which is not
appropriate for case 2., so I'll fix that.

we probably need another control variable optionally set in the
environment (PCP_NO_DERIVED?) to get the missing 2 behaviours.

is PCP_DERIVED_CONFIG="" OK for that? It just prevents any config being
loaded at all (case 4.)

Yep, if the empty string does the job, that's fine. And the PATH-like syntax (that I'd forgotten) for PCP_CONFIG_DERIVED does the job for the other case(s).

... what's the rationale for any framework to impose/expect a .d
suffix for a directory name?

just that Frank's earlier reply suggested the directory be called
"config.d", but OK I've
perished the thought :P

Good decision!

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