[pcp:master] reported: boolean / quantified operations for derived-metrics #github

[email protected] Integration <[email protected]> Wed, 15 Feb 2017 21:21:50 -0800
Newsgroups gmane.comp.sysutils.pcp
Message-ID <[email protected]>

[pcp:master] New Comment on Issue #270 boolean / quantified operations for derived-metrics ( https://github.com/performancecopilot/pcp/issues/270 )
By kmcdonell ( https://github.com/kmcdonell ) :

William, just starting to think about this (thanks for the prod) ... - boolean operators: your examples are relational operators that yield boolean values ... (a) would you expect the value to be a C-style integer with the value 0 (false) or 1 (true)? (b) do you want boolean operators as well (!, && and ||)? - quantification over instances: same question as above wrt value, and is none(x) needed (this is !some(x) or some(x) == 0), but more importantly, what is "x" ... it makes no sense for it to be a metric or an arithmetic expression, so I am guessing you want "x" to be a relational expression. - conversion: OK - historical values: that's messy and definitely not for Phase 1. - floating point literals: OK - defined(): not sure defined() conveys the right semantics ... for a metric x, it may be undefined (not in the PMNS), defined but fetch returns an error (e.g. PM_ERR_APPVERSION), defined but fetch returns no values, or defined and fetch returns one or more values ... I can't see this predicate being evaluated in real-time, so it would be true or false (and defined the resultant expression tree) whenever a new PMAPI context is established, i.e. at the second phase of semantic checking for derived metric expressions. Not sure exactly what's required here, but I suspect "defined and fetch returns one or more values" (and even that won't work robustly in some cases, e.g. the PM_ERR_NYI and PM_ERR_AGAIN PMDAs)