On 03/11/2016 07:22 AM, Ken McDonell wrote:
On 10/03/16 10:06, Mark Goodwin wrote:
...
But perhaps I should have just added PCP_DERIVED_CONFIG to pcp.conf,
(in which case 5d562064541 would still be OK but kind of redundant,
so I would probably revert it)
I don't believe PCP_DERIVED_CONFIG should be in pcp.conf.
it's currently not (in top-of-tree nor my patchset)
I think the sort of controls we'd like to have are:
1. PCP_DERIVED_CONFIG not set, and load default definitions from a known place
2. load from PCP_DERIVED_CONFIG _and_ load default definitions from a known
place (I want to augment the standard derived metrics with some of my own)
3. load from PCP_DERIVED_CONFIG and do _not_ load default definitions from a
known place
4. PCP_DERIVED_CONFIG not set, and do _not_ load derived metric definitions
I can see valid use cases for all 4.
agree
The status quo is 3 and 4 (depending on the setting of PCP_DERIVED_CONFIG).
yes
I think you're changing to 1. and 3. ...
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.)
... 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
Cheers
|