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.
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. The status quo is 3 and 4
(depending on the setting of PCP_DERIVED_CONFIG). I think you're
changing to 1. and 3. ... we probably need another control variable
optionally set in the environment (PCP_NO_DERIVED?) to get the missing 2
behaviours.
Also, I chose $PCP_VAR_DIR/config/derived to be alongside similar config
directories (pmchart, pmlogconf, pmlogger, pmie and others).
And I guess it probably should be derived.d for ansible and friends?
(and all those other config dirs be renamed too, which sounds like a QA
nightmare!!)
Whoa ... what? Is this Ansible you're referring to? ... what's the
rationale for any framework to impose/expect a .d suffix for a directory
name?
|