Business Opportunity

What	Removed	Added
Status	NEW	ASSIGNED
Assignee	pcp@oss.sgi.com	nathans@debian.org

What	Removed	Added
CC		kenj@internode.on.net

What	Removed	Added
CC		nathans@debian.org

What	Removed	Added
Status	NEW	ASSIGNED
CC		nathans@debian.org

What	Removed	Added
Status	ASSIGNED	RESOLVED
Resolution	---	FIXED

Thank you Lukas for your guidance and advise!

On Wed, May 6, 2015 at 7:52 PM, Lukas Berk <lberk@redhat.com><= /span> wrote:

Hi Mehran,

Mehran Saliminia <msaliminia@gma= il.com> writes:
[...]
> Since you are one of the main contributors of the PCP= github project,
> I would ask a couple of questions about the PCP-Installation from the<= br> > source code.

Sure, but in the future please considering sending this to a wider audience such as the pcp mailing list ( = pcp@oss.sgi.com ).=C2=A0 There is
a much greater amount of combined expertise on the list.

> I am going to install pcp from the source code and all its
> dependencies as well.
>
> Firstly, I want to have a packaging script for pcp, something like
> this, but for pcp and its dependencies:
>
> h= ttps://github.com/cloudfoundry/cf-release/blob/94bb01c0673d1d327b07e64dd771= 4d2f775748d3/packages/libpq/packaging
>
> We assume that we have everything locally so that we can install
> everything without any internet connection. without apt-get I mean.
Sounds like you should use the include Makepkgs script.=C2=A0 Assumi= ng you
have all the proper dependencies, it should build your .debs

> Secondly, I am going to have some ctrl script to start and stop pcp > processes. Something like this:
>
> https://github.com/cloudfoundry/cf-release/blob/94bb01c0673d1d327b07= e64dd7714d2f775748d3/jobs/etcd/templates/etcd_ctl.erb
>
> I don't want to use service pcp start/stop. I am going to install = pcp
> in a specific directory and be able to control all processes within my=
> script.

I suppose one could invoke the rc scripts we provide manually.=C2=A0= Due to
PCP's architecture there is commonly more than one service running base= d
on your desired setup/functionality.=C2=A0 More specificity on what
functionality is desired would be helpful.

Cheers,

Lukas

Mehran S= aliminia

Please consider the impact on the e= nvironment before printing this e-mail.

--f46d04428100a4e9a50515788431-- From mgoodwin@redhat.com Thu May 7 02:21:51 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 085CE7F37 for ; Thu, 7 May 2015 02:21:51 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id C60A28F8066 for ; Thu, 7 May 2015 00:21:47 -0700 (PDT) X-ASG-Debug-ID: 1430983305-04bdf063225d6a10001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id BL6q4J5JyLmi92Dw (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 00:21:46 -0700 (PDT) X-Barracuda-Envelope-From: mgoodwin@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t477Lj9L011562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 7 May 2015 03:21:45 -0400 Received: from [10.64.51.88] (vpn1-51-88.bne.redhat.com [10.64.51.88]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t477Lho6002291 for ; Thu, 7 May 2015 03:21:44 -0400 Message-ID: <554B1286.80405@redhat.com> Date: Thu, 07 May 2015 17:21:42 +1000 From: Mark Goodwin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: pcp Subject: pcp updates: merge Lukas (package split) + Nathan (pkg tweaks, qa) + Disseldorp (psproc) + mgoodwin (pkg tweaks) + Martins (linux_proc metric labels) Content-Type: text/plain; charset=windows-1252; format=flowed X-ASG-Orig-Subj: pcp updates: merge Lukas (package split) + Nathan (pkg tweaks, qa) + Disseldorp (psproc) + mgoodwin (pkg tweaks) + Martins (linux_proc metric labels) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1430983306 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 This is a rather large and important merge with pretty major RPM packaging changes in build/rpm/pcp.spec.in, as described below. The Fedora spec and Debian packaging are still future work. note: github is back up and the mirror has now sync'd again. Changes committed to git://git.pcp.io/pcp.git master Lukas Berk (28): Update pmdapapi papi_store function to actually loop through pmid's PR1073 - pmlogger --PID lifetime tracking functionality Separate Perl pmda's and pmda bindings Split python pmdas into their own sub packages move pmatop under pcp-atop move pmiostat under pcp-iostat move pmcollectl under pcp-collectl move pcp2graphite under pcp-2graphite Break src/pcp/ monitoring tools into their own sub package Robustify testsuite in cases prereqs aren't installed Tweak location of the pmda check notrun Add varios dependency checks for testcase 366 Move perl and python dependencies to their respective packages Separate non default pmdas written in C, robustify related tests Update spin-rawhide to address packaging guideline concerns Robustify testsuite a bit more Add pcp-compat package as per fedora packaging guidelines for existing fedoras Add pcp-system-tools to compat package Move man pages into the pcp-docs package If pcp-tool(1) program is not installed, have pcp.sh suggest installation Build the pmns during pcp setup in spec file Fix up pcp.spec.in after merge from 3.10.4 release mangled a few things Force restart for postfix pmda installation Add pcp-monitor and pcp-collection meta packages to pcp.spec.in Renable systemd pmda package with reworked regex in file selection Fix up Makefiles that were overwritten by merge adjust pcp.spec.in Rename pcp-pmda-nvidia rpm to pcp-pmda-nvidia-gpu Add pcp-doc to pcp-compat deps to avoid losing man pages on upgrade Nathan Scott (6): Tweak pcp-compat requires to main pcp package, fix spelling issues build: rpm packaging split updates building on Lukas' work build: pcp-pmda-systemtap package superceded by json qa: extend filters for 359 for some elasticsearch versions qa: make 769 handle existing outfile symlink override build: add rpm conflict handling for pcp command in librapi Martins Innus (2): Add new PM_ERR_BADSTORE error and other error fixups Label the metrics in store/fetch in pmdas/linux_proc David Disseldorp (1): Add configure psproc check for /bin/bash for open build systems Mark Goodwin (1): Fix rpm-devel issue in pcp.spec.in build/rpm/GNUmakefile | 5 build/rpm/fedora.spec | 3 build/rpm/pcp.spec.in | 1799 ++++++++++++++++++++++++++++++------- configure | 26 configure.ac | 26 man/man1/pmlogger.1 | 13 qa/.gitignore | 1 qa/006.out | 2 qa/1049 | 3 qa/1051 | 2 qa/154 | 3 qa/258 | 3 qa/323 | 3 qa/336 | 3 qa/346 | 3 qa/349 | 2 qa/355 | 3 qa/359 | 1 qa/366 | 10 qa/376 | 3 qa/379 | 3 qa/383 | 3 qa/421 | 3 qa/426 | 3 qa/445 | 3 qa/511 | 1 qa/525 | 3 qa/527 | 5 qa/537 | 5 qa/565 | 3 qa/597 | 3 qa/601 | 3 qa/602 | 2 qa/642 | 4 qa/656 | 3 qa/660 | 1 qa/670 | 4 qa/703 | 3 qa/711 | 1 qa/744 | 4 qa/745 | 4 qa/748 | 2 qa/755 | 4 qa/763 | 3 qa/769 | 36 qa/769.out | 8 qa/769.out.1 | 17 qa/769.out.2 | 21 qa/769.out.3 | 21 qa/769.out.4 | 25 qa/827 | 8 qa/947 | 46 qa/947.out | 8 qa/982.out | 2 qa/GNUmakefile | 8 qa/group | 1 qa/pmdas/GNUmakefile | 4 qa/pmdas/GNUmakefile.install | 4 qa/src/GNUlocaldefs | 4 scripts/spin-rawhide | 11 src/GNUmakefile | 5 src/include/builddefs.in | 5 src/include/pcp/pmapi.h | 1 src/libpcp/src/err.c | 2 src/pcp/2graphite/GNUmakefile | 64 - src/pcp/2graphite/pcp-2graphite.py | 538 +++++------ src/pcp/GNUmakefile | 10 src/pcp/atop/GNUmakefile | 33 src/pcp/atop/pcp-atop.py | 940 +++++++++++++++++++ src/pcp/collectl/GNUmakefile | 31 src/pcp/collectl/pcp-collectl.py | 705 ++++++++++++++ src/pcp/dmcache/GNUmakefile | 4 src/pcp/free/GNUmakefile | 4 src/pcp/iostat/GNUmakefile | 39 src/pcp/iostat/pcp-iostat.py | 211 ++++ src/pcp/numastat/GNUmakefile | 6 src/pcp/pcp.sh | 14 src/pcp/uptime/GNUmakefile | 4 src/pcp/verify/GNUmakefile | 4 src/pcp2graphite/GNUmakefile | 66 - src/pcp2graphite/pcp2graphite.py | 538 +++++------ src/perl/PMDA/PMDA.pm | 10 src/perl/PMDA/cvalue.c | 4 src/pmatop/GNUmakefile | 30 src/pmatop/pmatop.py | 940 ------------------- src/pmcollectl/GNUmakefile | 30 src/pmcollectl/pmcollectl.py | 705 -------------- src/pmdas/GNUmakefile | 12 src/pmdas/linux_proc/contexts.c | 4 src/pmdas/linux_proc/pmda.c | 424 ++++---- src/pmdas/logger/event.c | 2 src/pmdas/logger/logger.c | 2 src/pmdas/mmv/src/mmv.c | 2 src/pmdas/papi/papi.c | 57 - src/pmdas/pmcd/src/pmcd.c | 6 src/pmdas/postfix/Install | 2 src/pmdas/sample/src/sample.c | 12 src/pmdas/simple/GNUmakefile | 4 src/pmdas/simple/pmdasimple.perl | 6 src/pmdas/simple/pmdasimple.python | 6 src/pmdas/simple/simple.c | 6 src/pmdas/trace/src/trace.c | 2 src/pmiostat/GNUmakefile | 34 src/pmiostat/pmiostat.py | 211 ---- src/pmlogger/src/pmlogger.c | 24 src/python/GNUmakefile | 2 src/python/pmapi.c | 2 107 files changed, 4749 insertions(+), 3225 deletions(-) Details ... commit d49dadc5977493e3f28d44f2cbb66fdb25a91eb9 Author: Nathan Scott Date: Thu May 7 12:54:17 2015 +1000 build: add rpm conflict handling for pcp command in librapi Resolves oss BZ #859 as best we can hope to at this stage. commit c0d42038f3e8e96480adbfd32f2f837d8cf8347e Author: Nathan Scott Date: Thu May 7 12:40:34 2015 +1000 qa: make 769 handle existing outfile symlink override commit 2e06967decd7fd4624d4d316e47639bda2e23a85 Author: Nathan Scott Date: Thu May 7 12:40:08 2015 +1000 qa: extend filters for 359 for some elasticsearch versions commit 06a252de4e65845253b4f28bdee0812660789cc3 Author: Nathan Scott Date: Thu May 7 10:22:25 2015 +1000 build: pcp-pmda-systemtap package superceded by json Package was catching only the pmcd tapset, which belongs in pcp. commit 069d91e44f0edfb35f19415788535a432fa0bf42 Author: Lukas Berk Date: Wed May 6 17:45:14 2015 -0400 Add pcp-doc to pcp-compat deps to avoid losing man pages on upgrade Signed-off-by: Lukas Berk commit eeb32b2849375a1d84e9566ea96a30e1c89e3dae Author: Lukas Berk Date: Wed May 6 16:35:57 2015 -0400 Rename pcp-pmda-nvidia rpm to pcp-pmda-nvidia-gpu Using the name pcp-pmda-nvidia conflicts with older pcp versions, renaming this package avoids the 'conflicts' statements. Signed-off-by: Lukas Berk commit d8fa42ffabcc31b565a57f20037f90b328995add Author: Martins Innus Date: Wed May 6 15:20:22 2015 +0000 Label the metrics in store/fetch in pmdas/linux_proc commit d14849ae9fbe80cb625c90246c9b3e1ab56a8a2e Author: Nathan Scott Date: Wed May 6 16:23:42 2015 +1000 build: rpm packaging split updates building on Lukas' work Handful of smaller issues tackled here: - put in place back-compat symlinks for some py commands (needs to be makefile-driven too, not spec driven as this affects all build platforms, not rpm alone) - many commands support both py2 and py3, so switching over makefiles to py2 only was NQR - introduce HAVE_PYTHON for makefiles needing to know only if *some* supported python version has been found. - pcp2graphite packaging work, more like the other "2"pcp utilities (this one may need to become a daemon someday). - prefer python3 over python2 in packaging dependencies - fix conditionals around pcp-pmda-systemd package to make use of configure'd state, as per other pmda packages. commit cb5f2c1cc9bbf9e65cd0589dcd0f81f79bbac1b9 Author: David Disseldorp Date: Tue May 5 19:53:18 2015 -0400 Add configure psproc check for /bin/bash for open build systems commit 28b33e9bdc927383a947930939efbcc1785c207c Author: Mark Goodwin Date: Tue May 5 15:18:38 2015 -0400 Fix rpm-devel issue in pcp.spec.in commit a30a3fa475c8dab2e3368907a507a409cd5e9934 Author: Lukas Berk Date: Tue May 5 15:16:49 2015 -0400 Fix up Makefiles that were overwritten by merge adjust pcp.spec.in commit cb88f602c42ff489be6ea182f17c702bff484b62 Author: Martins Innus Date: Tue May 5 19:14:49 2015 +0000 Add new PM_ERR_BADSTORE error and other error fixups Add a new error code: PM_ERR_BADSTORE, deal with bad input to pmstore. Update the relevant pmdas to use this new code and generate new qa output for relevant tests. Add this code to the perl and python bindings. In doing so, I found some missing error codes, so added those. commit 629fc9f3621b54b866f84dbb27f1d08cd52a3a8a Author: Lukas Berk Date: Mon May 4 14:18:13 2015 -0400 Renable systemd pmda package with reworked regex in file selection commit 7a534c11b00247e5ef4b097b3d6b44c5e0d59177 Author: Nathan Scott Date: Mon May 4 10:21:31 2015 -0400 Tweak pcp-compat requires to main pcp package, fix spelling issues commit 1527fd1fe1d7cdf8a3babea34f4461b08bb530da Author: Lukas Berk Date: Tue Apr 28 18:25:02 2015 -0400 Add pcp-monitor and pcp-collection meta packages to pcp.spec.in To help in making installation of now-split pcp packges, pcp-monitor and pcp-collection meta packages will allow the user to easily choose a focused selection of packages. commit 17c48454790627e5a9ad2ff4273d94f026e16c20 Author: Lukas Berk Date: Tue Apr 28 09:58:56 2015 -0400 Force restart for postfix pmda installation The postfix pmda requires being installed by root to change the gid to postfix. Switch the required option in the Install script. commit 357c852d019086aa492841a4f770db5d6b8604d0 Author: Lukas Berk Date: Tue Apr 21 09:46:03 2015 -0400 Fix up pcp.spec.in after merge from 3.10.4 release mangled a few things commit 6fede86a8c57d0bd70de9fda8d2cde862e450511 Author: Lukas Berk Date: Thu Apr 16 10:39:39 2015 -0400 Build the pmns during pcp setup in spec file Attempt to build the pmns during pcp installation (not pmcd service start) commit 0586b9a24714abcb53536d6228b0a100d02de919 Author: Lukas Berk Date: Thu Mar 26 11:24:58 2015 -0400 If pcp-tool(1) program is not installed, have pcp.sh suggest installation Since the pcp-python tools have been split into their own package, it would be helpful to suggest a package to install (pcp-system-tools). Lets do that. Perhaps later we can detect the OS/linux distro, and give a most specific command the user could simply copy and paste. commit 428db3eb12bb0dc20e211f26bf5be0aa6d9cc1fe Author: Lukas Berk Date: Thu Mar 26 11:23:53 2015 -0400 Move man pages into the pcp-docs package commit 802217875e36f86a8de0f597bbb540d06b93aea2 Author: Lukas Berk Date: Tue Mar 24 17:33:12 2015 -0400 Add pcp-system-tools to compat package commit bd1424aec55a292b6934673caeb1f24d5a817d54 Author: Lukas Berk Date: Tue Mar 24 17:31:25 2015 -0400 Add pcp-compat package as per fedora packaging guidelines for existing fedoras In order to not break existing installs on fedora, we need to create a compat package, that is temporary, to require the (now optional) packages commit 37f6675fd0b578827a81042e43c336cf7689e674 Author: Lukas Berk Date: Tue Mar 24 15:00:02 2015 -0400 Robustify testsuite a bit more A few more fixes after breaking C pdma's into their own packages commit 3467d8a883badd9fcaf560c1397d24420f666696 Author: Lukas Berk Date: Mon Mar 23 10:45:03 2015 -0400 Update spin-rawhide to address packaging guideline concerns some fedora packing guidelines were raised in BZ1204467 addressing the versioning issues caused by spin-rawhide here. Also updating the location of webjs sources. commit 7c9ef29b17d43625fbaa17fc8e6f9e488339d6b4 Author: Lukas Berk Date: Fri Mar 20 18:29:48 2015 -0400 Separate non default pmdas written in C, robustify related tests build/rpm/pcp.spec.in - apache, bash, cifs, cisco, gfs2, lmsensors, mailq, mounts, nvidia, roomtemp, rpm, sendmail, shping, summary, trace, weblog pmdas seperated qa/* - update various testcases if components are not installed commit a8156519db19c03ec4f779d3f57494c45af74938 Author: Lukas Berk Date: Wed Mar 18 17:52:09 2015 -0400 Move perl and python dependencies to their respective packages Have the base perl/python dependencies move to the specific library binding packages instead of the base PCP. commit e8fd4b0542837debea42fbd8fd0a7984b0ac99f3 Author: Lukas Berk Date: Wed Mar 18 17:51:34 2015 -0400 Add varios dependency checks for testcase 366 qa/366 add notrun checks for the pmda it tests with commit 254547f81a78313b395bdedf40df57056a741b3f Author: Lukas Berk Date: Tue Mar 17 14:45:57 2015 -0400 Tweak location of the pmda check notrun We need to place the notfun check to after setting the seq variable commit 6372579317808e96ba4f0ab2886c500d2020801a Author: Lukas Berk Date: Mon Mar 16 16:58:21 2015 -0400 Robustify testsuite in cases prereqs aren't installed qa/511 - check for sar2pcp qa/527 - check for perl deps qa/537 - check for pcp perl deps qa/660 - check for pmwebd installation qa/711 - check for sar2pcp qa/748 - check for mysql pmda installation qa/763 - check for pcp perl deps qa/769 - alter what we check for based on if pmmgr or pmwebd is installed qa/769.out - make generic out file to symlink against qa/769.out.1 - case where pmmgr and pmwebd are not installed qa/769.out.2 - case were pmwebd is installed but not pmmgr qa/769.out.3 - case were pmmgr is installed but not pmwebd qa/769.out.4 - case where both are installed qa/827 - check for snmp pmda installation commit 26abc673c6371e60116eb6f809af76990e605e55 Author: Lukas Berk Date: Sat Mar 14 12:24:39 2015 -0400 Break src/pcp/ monitoring tools into their own sub package Move pcp2graphite, atop, collectl, dmcache, free, iostat, numastat and uptime into their own subpackage. Add symlinks for pcp2graphite, atop, collectl and iostat for /usr/bin/pm* variants and backwards compat. commit 26b4b34d822624ba4b09a56f7a2f84c60285012b Author: Lukas Berk Date: Fri Mar 13 23:31:20 2015 -0400 move pcp2graphite under pcp-2graphite src/GNUmakefile - remove pcp2graphite src/pcp/GNUmakefile - added 2graphite subdir renamed: pcp2graphite/{GNUmakefile,pcp2graphite.py} to pcp/2graphite/{GNUmakefile,pcp-2collect.py} commit 4dcc057bf472798d6b40256ba2c970eca729a928 Author: Lukas Berk Date: Fri Mar 13 22:22:39 2015 -0400 move pmcollectl under pcp-collectl src/GNUmakefile - remove pmcollectl subdir src/pcp/GNUmakefile - added collectl subdir renamed: pmcollectl/{GNUmakefile,pmcollectl.py} to pcp/collectl/{GNUmakefile,pcp-collectl.py} commit 3c2810eda48ffef49638d9c465c023baf18db448 Author: Lukas Berk Date: Fri Mar 13 21:52:31 2015 -0400 move pmiostat under pcp-iostat src/GNUmakefile - remove pmiostat subdir src/pcp/GNUmakefile - added iostat subdir rename: pmiostat/{GNUmakefile,pmiostat.py} to pcp/atop/{GNUmakefile,pcp-iostat.py} commit 7ea262c80adcaa39b3073e70f424969f1acea7e9 Author: Lukas Berk Date: Fri Mar 13 21:37:18 2015 -0400 move pmatop under pcp-atop bulid/rpm/pcp.spec.in - adjust ordering of python and python3 src/GNUmakefile - removed pmatop subdir src/pcp/GNUmakefile - add atop subdir renamed: pmatop/{GNUmakefile,pmatop.py} to pcp/atop/{Gnumakefile, pcp-atop.py} commit 511b195bbe4cc21e102a5c34c500883c29b659cd Author: Lukas Berk Date: Fri Mar 13 16:26:55 2015 -0400 Split python pmdas into their own sub packages To simplify things, use a macro at the start of the spec file, which is activated regardless of the version of python. Also make enable_python explicitly python2. commit 89b4a868275893be874fe01a94428bdb12cc81a0 Author: Lukas Berk Date: Fri Mar 13 10:57:52 2015 -0400 Separate Perl pmda's and pmda bindings Break each perl pmda into their own subpackage commit 7347927a67849a74b67d8b25fb58c033ee79042d Author: Lukas Berk Date: Thu Feb 26 14:13:21 2015 -0500 PR1073 - pmlogger --PID lifetime tracking functionality PR1073 detailed a request to run an instance of pmlogger, which matched the lifetime of a specified PID. Monitor return of a kill(PID, 0) style call, and exit once we get an ESRCH (no such process) error. Updated doc pmlogger (1), and additional qa (947) added to the pmlogger testing group. commit fe589e5131230c07174726b9add24b00ed1c6421 Author: Lukas Berk Date: Sun Feb 22 20:12:06 2015 -0500 Update pmdapapi papi_store function to actually loop through pmid's src/pmdas/papi/papi.c - pmstore now loops through numpmid's instead of immediately breaking after the first pmid From kenj@internode.on.net Thu May 7 02:29:18 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id A89DE7F37 for ; Thu, 7 May 2015 02:29:18 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 924668F809B for ; Thu, 7 May 2015 00:29:18 -0700 (PDT) X-ASG-Debug-ID: 1430983755-04cbb056b25c9bf0001-S8gJnT Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id ka7A8E6LseJ5mxe3 for ; Thu, 07 May 2015 00:29:16 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DwAQCUE0tVPKEh0XYNT4dcgy6/JIR9gl4CgWATAQEBAQEBAQYBAQEBQYRfAQEBAwEjFUABEAsYAgIFFgsCAgkDAgECATEUBgEMAQcBAYggsHVwky4BAQEBAQEBAwEBAQEBAQEBGoEhihiFBQeCaIFFAQSzOYQrgyIBAQE Received: from ppp118-209-33-161.lns20.mel4.internode.on.net (HELO [192.168.1.100]) ([118.209.33.161]) by ipmail05.adl6.internode.on.net with ESMTP; 07 May 2015 16:59:15 +0930 Message-ID: <554B144A.4050007@internode.on.net> Date: Thu, 07 May 2015 17:29:14 +1000 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Nathan Scott , Marko Myllynen CC: pcp@oss.sgi.com Subject: Re: [pcp] Calculated/derived metrics? References: <5534C680.2020709@redhat.com> <5534EBA8.4030509@redhat.com> <1644393599.3651017.1429563442835.JavaMail.zimbra@redhat.com> <55364606.1000503@redhat.com> <55472B40.7050800@redhat.com> <5547DE11.5050800@internode.on.net> <5549E4CD.5000408@redhat.com> <554AFE4E.80000@internode.on.net> <2018532257.14377924.1430979561523.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] Calculated/derived metrics? In-Reply-To: <2018532257.14377924.1430979561523.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1430983755 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18690 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 07/05/15 16:19, Nathan Scott wrote: > > A few possibilities spring to mind ... > - presenting some pmchart UI for adding new derivations interactively > (may need a parser-helper routine for this that pmchart can use to > give feedback about parsing error locations), This is also on the BZ list. But there is a potential problem, derived metrics only work for the current set of definitions at the time of a pmNewContext() or pmReconnectContext() ... so presenting the currently derived metrics in a UI component is OK (assuming we had some new API to export this from libpcp), but if the UI was to allow the definition of new derived metric expressions this could be very disruptive to the client (from the client's perspective close and open all contexts is the same as pmcd being restarted). > - provide a mechanism to persist derivations (in ~/.pcp/ &| /etc/pcp) > and make libpcp automatically load those metrics so that all client > tools see 'em immediately (without env vars, etc). Yep that's certainly possible, although if that directory gets cluttered it could significantly slow PMAPI operations both at startup and on the error paths (derived metrics are usually tried when all else fails for pmns and metadata operations). If we can gather these definitions from a number of places ... env, /etc/pcp/.., ~/.pcp, command line args ... then there is a more pressing need for an export API. > - as we find useful, general derivations we could install them below > /etc/pcp (ie as part of the package installation) so they're always > automatically available Nod. >>> I don't see Perl bindings for this, not sure is that a biggie. ... >> >> The Python bindings are probably there by accident (no Python code appears to >> be using them). Perl bindings would be simple to add if the need arose. > > There are no general PMAPI perl client bindings (only the PMDA APIs). Ah, good point. From kenj@internode.on.net Thu May 7 02:30:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 0A15F7F37 for ; Thu, 7 May 2015 02:30:40 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id F29AA8F80A6 for ; Thu, 7 May 2015 00:30:39 -0700 (PDT) X-ASG-Debug-ID: 1430983834-04cb6c1cca56c1e0001-S8gJnT Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id npDGdHwqWBGkV1vb for ; Thu, 07 May 2015 00:30:35 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DwAQCUE0tVPKEh0XYNT4NgXoMegy63AYgjgU6HbxMBAQEBAQEBBgEBAQFBhQlVMAYCBRYLAgsDAgECATEnBgIBAbkVcJNagSGORYNHgUUFhlaPZoJGhV+UWIQrXYEDgUIBAQE Received: from ppp118-209-33-161.lns20.mel4.internode.on.net (HELO [192.168.1.100]) ([118.209.33.161]) by ipmail05.adl6.internode.on.net with ESMTP; 07 May 2015 17:00:33 +0930 Message-ID: <554B1499.3010201@internode.on.net> Date: Thu, 07 May 2015 17:30:33 +1000 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: pcp updates - misc Content-Type: text/plain; charset=utf-8 X-ASG-Orig-Subj: pcp updates - misc Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1430983834 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18690 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Definitely some review worthy stuff here. Changes committed to git://git.pcp.io/kenj/pcp master Ken McDonell (5): pmda.h: refine PMDA_PMID macro PM_ERR_BADSTORE: second round of cosmetic changes src/perl/PMDA/cvalue.c: another PM_ERR_* place src/perl/PMDA/Makefile.PL: Perl voodoo so that test.pl runs OK qa/771: (new) exercise test.pl/cvalue.c from the perl PMDA bindings qa/771 | 36 ++++++++++++++++++++++++++++++++++++ qa/GNUmakefile | 2 +- qa/group | 1 + qa/perl/GNUmakefile | 26 ++++++++++++++++++++++++++ qa/perl/GNUmakefile.install | 1 + qa/perl/Makefile | 2 ++ src/include/pcp/pmda.h | 8 ++++++-- src/libpcp/src/err.c | 15 ++++++++++++++- src/perl/PMDA/Makefile.PL | 17 +++++++++++++++++ src/perl/PMDA/PMDA.pm | 26 ++++++++++++++++---------- src/perl/PMDA/cvalue.c | 44 +++++++++++++++++++++++++++++++------------- src/python/pmapi.c | 18 +++++++++++------- 12 files changed, 162 insertions(+), 34 deletions(-) Details ... commit 3884040a45e6a55e6fd8a4895847602fa391785c Author: Ken McDonell Date: Thu May 7 17:13:13 2015 +1000 qa/771: (new) exercise test.pl/cvalue.c from the perl PMDA bindings Need to reach across to the src directory to get the test.pl and cvalue.c bits (in the build), then execute the test in the (new) perl subdirectory. commit b1aaca27ffba17b49069e233c3d86fcc0ff618c8 Author: Ken McDonell Date: Thu May 7 09:58:59 2015 +1000 src/perl/PMDA/Makefile.PL: Perl voodoo so that test.pl runs OK Really obscure MakeMaker hack needed to allow make -f Makefile test to actually work, rather than dying as in ... kenj@bozo-vm:~/src/pcp/src/perl/PMDA$ make -f Makefile test PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl 1..4 Can't load 'blib/arch/auto/PCP/PMDA/PMDA.so' for module PCP::PMDA: blib/arch/auto/PCP/PMDA/PMDA.so: undefined symbol: clearHV at /usr/lib/perl/5.14/DynaLoader.pm line 184. at test.pl line 21 Compilation failed in require at test.pl line 21. commit 453459a12cb76d19bcb8d3f94a8e20d3cbcf86a8 Author: Ken McDonell Date: Thu May 7 09:56:19 2015 +1000 src/perl/PMDA/cvalue.c: another PM_ERR_* place 1. fix ordering of error code tests here to match pmerr -l order 2. make ids() more data driven 3. extend ids() to check PMDA_PMID() and pmid_build() return the same value ... really a pmda.h test rather than a perl test but fits conveniently here commit 40b1c6f3b979b2a747545bfaebef3a7c8dd04cbd Author: Ken McDonell Date: Thu May 7 09:26:24 2015 +1000 PM_ERR_BADSTORE: second round of cosmetic changes In the places where we enumerate PM_ERR_* values and need to keep them in sync (Perl and Python bindings in particular), make the order the same as pmerr -l to ease maintenance. And document this goal in all 3 places. Note the order in pmapi.h is different, but that serves a different purpose and is OK to be different. commit 056c9d30fe109e858755f856a374e9ef7fad258e Author: Ken McDonell Date: Thu May 7 09:22:36 2015 +1000 pmda.h: refine PMDA_PMID macro In some unrelated testing I discovered that PMDA_PMID(x,y) and build_pmid(0,x,y) don't return the same values for some choices of x and y! In particular if the arguments to PMDA_PMID() are negative (!) or larger than the corresponding field widths the PMDA_PMID() value is clearly wrong. Add some masking to limit x (cluster) to 12 bits and y (item) to 10 bits. From kenj@internode.on.net Thu May 7 02:39:32 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id A8C8A7F37 for ; Thu, 7 May 2015 02:39:32 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 7F1EE30404E for ; Thu, 7 May 2015 00:39:29 -0700 (PDT) X-ASG-Debug-ID: 1430984366-04bdf063205d7010001-S8gJnT Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id 1ts4tkLKuaOdkZwb for ; Thu, 07 May 2015 00:39:27 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DvAQA0FktVPKEh0XYNT4NgXoMegy6/GYFOh28TAQEBAQEBAQYBAQEBQYUJFUAwBgIFFgsCCwMCAQIBMScGAgEBuQ1wk1qBIY86glKBRQWWPJx9hCtdgkUBAQE Received: from ppp118-209-33-161.lns20.mel4.internode.on.net (HELO [192.168.1.100]) ([118.209.33.161]) by ipmail05.adl6.internode.on.net with ESMTP; 07 May 2015 17:09:26 +0930 Message-ID: <554B16AE.1010204@internode.on.net> Date: Thu, 07 May 2015 17:39:26 +1000 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: pcp updates - fixup Content-Type: text/plain; charset=utf-8; format=flowed X-ASG-Orig-Subj: pcp updates - fixup Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1430984366 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18690 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Just pushing this minor one, and making sure the resolution of the overlapping merge (qa/GNUmakefile) in my last re-sync with the official tree makes it back to my oss tree. Changes committed to git://git.pcp.io/kenj/pcp master Ken McDonell (1): src/perl/PMDA/.gitignore: cvalue executable is not interesting src/perl/PMDA/.gitignore | 1 + 1 file changed, 1 insertion(+) Details ... commit af7310944455af885a42a6545f56d3d63eae7b9e Author: Ken McDonell Date: Thu May 7 17:34:11 2015 +1000 src/perl/PMDA/.gitignore: cvalue executable is not interesting From myllynen@redhat.com Thu May 7 05:20:41 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id AE3D67F37 for ; Thu, 7 May 2015 05:20:41 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 8C4478F8037 for ; Thu, 7 May 2015 03:20:38 -0700 (PDT) X-ASG-Debug-ID: 1430994037-04cb6c1cc9572240001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id BKjktkAEhWsp4NGc (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 03:20:37 -0700 (PDT) X-Barracuda-Envelope-From: myllynen@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id ECD035A094; Thu, 7 May 2015 10:20:36 +0000 (UTC) Received: from mmyllyne.csb (vpn1-7-207.ams2.redhat.com [10.36.7.207]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t47AKZ04014484; Thu, 7 May 2015 06:20:35 -0400 Message-ID: <554B3C72.3060306@redhat.com> Date: Thu, 07 May 2015 13:20:34 +0300 From: Marko Myllynen Reply-To: myllynen@redhat.com Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ken McDonell , Nathan Scott CC: pcp@oss.sgi.com Subject: Re: [pcp] Calculated/derived metrics? References: <5534C680.2020709@redhat.com> <5534EBA8.4030509@redhat.com> <1644393599.3651017.1429563442835.JavaMail.zimbra@redhat.com> <55364606.1000503@redhat.com> <55472B40.7050800@redhat.com> <5547DE11.5050800@internode.on.net> <5549E4CD.5000408@redhat.com> <554AFE4E.80000@internode.on.net> <2018532257.14377924.1430979561523.JavaMail.zimbra@redhat.com> <554B144A.4050007@internode.on.net> X-ASG-Orig-Subj: Re: [pcp] Calculated/derived metrics? In-Reply-To: <554B144A.4050007@internode.on.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1430994037 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi, On 2015-05-07 10:29, Ken McDonell wrote: > On 07/05/15 16:19, Nathan Scott wrote: >> >> A few possibilities spring to mind ... >> - presenting some pmchart UI for adding new derivations interactively >> (may need a parser-helper routine for this that pmchart can use to >> give feedback about parsing error locations), > > This is also on the BZ list. I see PCP_DERIVED_CONFIG commented out in pmwebd.options, I presume predefined derived metrics are thus available via pmwebd for Web UIs? >> - provide a mechanism to persist derivations (in ~/.pcp/ &| /etc/pcp) >> and make libpcp automatically load those metrics so that all client >> tools see 'em immediately (without env vars, etc). > > Yep that's certainly possible, although if that directory gets cluttered > it could significantly slow PMAPI operations both at startup and on the > error paths (derived metrics are usually tried when all else fails for > pmns and metadata operations). I added PCP_DERIVED_CONFIG to /etc/pcp.conf and all of pminfo, pmval, and pmdumptext "just worked" with derived metrics. Not sure is this the ideal solution but if no better ones are in sight then perhaps adding PCP_DERIVED_CONFIG to pcp.conf in comments might be somewhat helpful. > If we can gather these definitions from a number of places ... env, > /etc/pcp/.., ~/.pcp, command line args ... then there is a more pressing > need for an export API. Having some examples provided or a "library of derived metrics" would certainly help - few weeks ago I was asking about using PCP as a 1:1 drop-in replacement for sar/sysstat and otherwise it's already possible but there were three (or four) metrics that were not readily available (disk.dev.avqsz, disk.dev.avrqsz, disk.dev.await, disk.dev.svctm), it might be a nice real world example that even if such calculated metrics are not provided by default, they can be derived. (The needed calculations should already be present in a slightly different form in pmiostat I presume). >> - as we find useful, general derivations we could install them below >> /etc/pcp (ie as part of the package installation) so they're always >> automatically available > > Nod. Yup. >>>> I don't see Perl bindings for this, not sure is that a biggie. ... >>> >>> The Python bindings are probably there by accident (no Python code >>> appears to >>> be using them). Perl bindings would be simple to add if the need arose. >> >> There are no general PMAPI perl client bindings (only the PMDA APIs). > > Ah, good point. Ok so with Perl scripts one would just defined the env variable? Thanks, -- Marko Myllynen From myllynen@redhat.com Thu May 7 05:29:42 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 918A77F37 for ; Thu, 7 May 2015 05:29:42 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 83F25304043 for ; Thu, 7 May 2015 03:29:39 -0700 (PDT) X-ASG-Debug-ID: 1430994577-04cbb056b25cfae0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id N2oC3YPwXXgCSug6 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 03:29:38 -0700 (PDT) X-Barracuda-Envelope-From: myllynen@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t47ATbAU032250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 7 May 2015 06:29:37 -0400 Received: from mmyllyne.csb (vpn1-7-207.ams2.redhat.com [10.36.7.207]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t47ATal1000408 for ; Thu, 7 May 2015 06:29:36 -0400 Message-ID: <554B3E8F.3080904@redhat.com> Date: Thu, 07 May 2015 13:29:35 +0300 From: Marko Myllynen Reply-To: myllynen@redhat.com Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: Re: [pcp] Calculated/derived metrics? References: <5534C680.2020709@redhat.com> <493537984.3276058.1429528962326.JavaMail.zimbra@redhat.com> <5534EBA8.4030509@redhat.com> <1644393599.3651017.1429563442835.JavaMail.zimbra@redhat.com> <55364606.1000503@redhat.com> <55472B40.7050800@redhat.com> <5547DE11.5050800@internode.on.net> <5549E4CD.5000408@redhat.com> <554AFE4E.80000@internode.on.net> X-ASG-Orig-Subj: Re: [pcp] Calculated/derived metrics? In-Reply-To: <554AFE4E.80000@internode.on.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1430994578 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi Ken, On 2015-05-07 08:55, Ken McDonell wrote: > On 06/05/15 19:54, Marko Myllynen wrote: >> ... right, I was blissfully unaware of this. > > I suspect that might be a common occurrence ... not sure how/where we > need to advertise the derived metrics capabilities so they are more > visible and the degree of blissful unawareness is reduced for the > wider audience. > > Suggestions would be most welcome here. once I understand this a bit better myself I'll send a patch to add a note about derived metrics in the PCP Quick Guide. I did search for "calculate" and "derive" from the books but didn't find anything about derived metrics from there. >> .. I see that pmRegisterDerived(3) describes both C API and the >> expressions used to construct derived metrics. There are also >> Python bindings for it. And pminfo(1) can read such a "dmfile" >> specified with -c, PCP_DERIVED_CONFIG should be used with tools >> like pmval(1). > > Mostly this was intended to work _without_ client change which is why > none of pmie, pmval, pmlogger, ... have any command line option to > force derived metrics to be loaded ... they all rely on the > environment variable mechanism so that derived metrics "just appear" > like regular metrics. > > pminfo is the odd one out because it is the swiss army knife that is > used to provide access to all manner of PMAPI services that are not > usually required by other, more useful (outside development and > debugging) client applications. Ok, makes sense. >> write_per_sec = hotproc.io.write_bytes / (kernel.all.uptime - >> hotproc.psinfo.start_time/100) >> >> leads to an (expected) error as there are several instances. ... > > The error is not really expected, has nothing to do with instances > and is confounded by close-to indecipherable error message !! > > Instances are fully supported in derived metrics. Aha, sounds good. > The problem in your example is that the expression involves the > counter hotproc.io.write_bytes and this is being divided by something > with the units of time that is not a counter. This is not allowed > because the semantics of the resulting expression are not well > defined ... is it a counter or instantaneous, and if a counter what > does the divisor in units of seconds really mean? > > I think what you want is to have hotproc.io.write_bytes treated as an > instantaneous value (the value now, not a counter). Is that > correct? Yes, correct (see below also). > And I'm not sure why the /100 is required, could you please explain > that part? kernel.all.uptime is in seconds but hotproc.psinfo.start_time is in jiffies and although jiffies-to-seconds is not necessarily a trivial operation [1], /100 seemed to provide "close enough" results during my tests. So it'd be "bytes written by the process during its lifetime / the lifetime of the process in seconds" which should then illustrate a average-bytes-written-per-second metric for the process. 1) http://unix.stackexchange.com/questions/7870/how-to-check-how-long-a-process-has-been-running/7871#comment9851_7873 > Now the example. > > I've replaced hotproc.io.write_bytes by hotproc.psinfo.rss, not > because this makes semantic sense, but because hotproc.psinfo.rss has > instantaneous semantics which would be the same as > value(hotproc.io.write_bytes) if that was implemented. > > kenj@bozo-vm:/var/log/pcp/pmcd$ PCP_DERIVED_CONFIG=/tmp/eek.derive > pminfo -df mytest > > Note we have 2 instances throughout and the expressions parse > correctly. > > Let me know if I've guessed your semantics correctly and I should add > value(v) to my RFE queue. It certainly sounds like it, hopefully the additional explanation above also provides more context on what I was after. Now, if we're in the business of adding more stuff to your RFE queue.. ;-) Would you see it feasible to use derived metrics to derive metrics? For example, in your example you had: mytest.divisor = hotproc.psinfo.start_time - kernel.all.uptime mytest.marko = hotproc.psinfo.rss / (hotproc.psinfo.start_time - kernel.all.uptime) It would be nice to be able to write this as: mytest.divisor = hotproc.psinfo.start_time - kernel.all.uptime mytest.marko = hotproc.psinfo.rss / mytest.divisor In this kind of simple case it's not hugely helpful but it might quickly become handy, I'd presume already with those few examples I mentioned in my previous email both reading and writing of those derived metrics would already get much easier. Thanks a lot for your help, things are now certainly getting clearer. Cheers, -- Marko Myllynen From myllynen@redhat.com Thu May 7 05:38:05 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id ECD6F7F37 for ; Thu, 7 May 2015 05:38:05 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id CC5848F809C for ; Thu, 7 May 2015 03:38:05 -0700 (PDT) X-ASG-Debug-ID: 1430995084-04cb6c1cc9572e90001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id tEE0sWlVBKNb8uAo (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 03:38:04 -0700 (PDT) X-Barracuda-Envelope-From: myllynen@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t47Ac3lI001866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 7 May 2015 06:38:04 -0400 Received: from mmyllyne.csb (vpn1-7-207.ams2.redhat.com [10.36.7.207]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t47Ac22D004602 for ; Thu, 7 May 2015 06:38:03 -0400 Message-ID: <554B408A.2020200@redhat.com> Date: Thu, 07 May 2015 13:38:02 +0300 From: Marko Myllynen Reply-To: myllynen@redhat.com Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: Re: [pcp] [PATCH] PCP pidstat PMDA References: <5534C680.2020709@redhat.com> <493537984.3276058.1429528962326.JavaMail.zimbra@redhat.com> <5534EBA8.4030509@redhat.com> <1644393599.3651017.1429563442835.JavaMail.zimbra@redhat.com> <55364606.1000503@redhat.com> <5536CF59.6050108@internode.on.net> X-ASG-Orig-Subj: Re: [pcp] [PATCH] PCP pidstat PMDA In-Reply-To: <5536CF59.6050108@internode.on.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1430995084 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi, just for the record / archives.. On 2015-04-22 01:29, Ken McDonell wrote: > On 21/04/15 22:43, Marko Myllynen wrote: >> ... >> hmm, so it is possible to provide a redirected metric from another >> domain in C but is there a way to do that in Perl or Python? And is it >> possible to read a metric from another domain to be used to calculate or >> construct a new metrics in the current domain, not just redirect? > > In general this is not possible. > > Think about the flow of a request (you're building pmda A and pmda B has > the metrics you're interested in): > > client -> pmcd -> pmda A -> ??? > > If pmda A tries to use pmcd to get to pmcd B we have a callback into > pmcd and all sorts of timeout headaches ... pmie in "secret agent mode" > for the summary PMDA does this, but I would not recommend that as a > precedent to be copied! > > If pmda B has some non-pcp export channel (as well) that could be used. > > Otherwise, source code replication from pmda B into pmda A is likely to > be the simplest (and most efficient) strategy. I think derived metrics would be helpful in the case I was thinking, i.e., to construct a new metric based on metrics provided by pmda A and by pmda B. Thanks, -- Marko Myllynen From minnus@buffalo.edu Thu May 7 10:03:43 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 3F2527F37 for ; Thu, 7 May 2015 10:03:43 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 1CCB38F809E for ; Thu, 7 May 2015 08:03:39 -0700 (PDT) X-ASG-Debug-ID: 1431010979-04cb6c1cc957aff0001-S8gJnT Received: from mtareserve1.acsu.buffalo.edu (mtareserve3.acsu.buffalo.edu [128.205.7.163]) by cuda.sgi.com with ESMTP id k2fjOwFHmPKtZvgJ for ; Thu, 07 May 2015 08:02:59 -0700 (PDT) X-Barracuda-Envelope-From: minnus@buffalo.edu X-Barracuda-Apparent-Source-IP: 128.205.7.163 Received: from localmailg.acsu.buffalo.edu (localmailg.acsu.buffalo.edu [128.205.4.25]) by mtareserve1.acsu.buffalo.edu (Postfix) with ESMTP id 0563A38FE for ; Thu, 7 May 2015 11:02:59 -0400 (EDT) Received: from localmailg.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D941AE098E for ; Thu, 7 May 2015 11:03:00 -0400 (EDT) Received: from localmailg.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailg.acsu.buffalo.edu (Postfix) with ESMTP id EB38EE0990 for ; Thu, 7 May 2015 11:02:59 -0400 (EDT) Received: from smtp.buffalo.edu (smtp3.acsu.buffalo.edu [128.205.5.226]) by localmailg.acsu.buffalo.edu (Prefixe) with ESMTP id EA205E098E for ; Thu, 7 May 2015 11:02:59 -0400 (EDT) Received: from [128.205.40.46] (slash.ccr.buffalo.edu [128.205.40.46]) (Authenticated sender: minnus@buffalo.edu) by smtp.buffalo.edu (Postfix) with ESMTPSA id 05EEB68C84 for ; Thu, 7 May 2015 11:02:58 -0400 (EDT) Message-ID: <554B7E8C.5040603@buffalo.edu> Date: Thu, 07 May 2015 11:02:36 -0400 From: Martins Innus User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: pmda timeout workarounds Content-Type: text/plain; charset=utf-8; format=flowed X-ASG-Orig-Subj: pmda timeout workarounds Content-Transfer-Encoding: 7bit X-PM-EL-Spam-Prob: : 8% X-Barracuda-Connect: mtareserve3.acsu.buffalo.edu[128.205.7.163] X-Barracuda-Start-Time: 1431010979 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18699 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- HI, I'd like to come back to this question that's been floating around for a while. When pmdas take too long to respond to a client request, pmcd gives up on them and closes the pipe. Roughly once or twice a day, usually coinciding with high I/O, we have pmdas that run into this situation: [Thu Apr 23 12:01:40] pmcd(1470) Warning: pduread: timeout (after 5.000 sec) while attempting to read 12 bytes out of 12 in HDR on fd=16 [Thu Apr 23 12:01:40] pmcd(1470) Info: CleanupAgent ... Cleanup "slurm" agent (dom 23): protocol failure for fd=16, exit(1) [Fri May 1 13:30:50] pmcd(1470) Warning: pduread: timeout (after 5.000 sec) while attempting to read 12 bytes out of 12 in HDR on fd=30 [Fri May 1 13:30:52] pmcd(1470) Info: CleanupAgent ... Cleanup "gpfs" agent (dom 135): protocol failure for fd=30, exit(1) [Fri May 1 13:31:20] pmcd(1470) Warning: pduread: timeout (after 5.000 sec) while attempting to read 12 bytes out of 12 in HDR on fd=12 [Fri May 1 13:31:22] pmcd(1470) Info: CleanupAgent ... Cleanup "proc" agent (dom 3): protocol failure for fd=12 We'd like to not increase the timeout, since in some cases, late data is worse than no data. There was some some discussion here that it should be handled on the pmda side: http://oss.sgi.com/bugzilla/show_bug.cgi?id=1036 Later on, some discussion on providing some new functionality: http://www.pcp.io/pipermail/pcp/2014-March/004586.html The slow startup has already been handled, but now I'm thinking about how to deal with slow responses when the pmda is already running. Barring any other suggestions, my plan would be to handle these issues on a case by case basis depending on the semantics of the pmda data. For the slurm pmda, the data is tolerant to some reporting drift so I would have a separate thread that updates a shared data structure periodically, and any fetch just reports the most recent information. For gpfs, we really care about getting the counters in a timely fashion. So can I just return PM_ERR_AGAIN to a client request for a pmda fetch if the request is taking too long, and the client will do "the right thing"? Where the right thing for a pmlogger instance is to probably record no value for that timestep. Proc probably would be a mix of these 2 solutions depending on the metric. Is that the right way forward, or any other suggestions? This has started to occur more and more for us as we develop pmdas that interact with systems that may introduce delays that we cannot control. Thanks Martins From lberk@redhat.com Thu May 7 10:15:40 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 8CD727F37 for ; Thu, 7 May 2015 10:15:40 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 7D07B30404E for ; Thu, 7 May 2015 08:15:40 -0700 (PDT) X-ASG-Debug-ID: 1431011738-04cb6c1cc757b610001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id JSab0YFb7zZfbERo (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 08:15:39 -0700 (PDT) X-Barracuda-Envelope-From: lberk@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t47FFcCk030227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 7 May 2015 11:15:38 -0400 Received: from toium (unused-10-15-17-202.yyz.redhat.com [10.15.17.202]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t47FFb3i028175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 May 2015 11:15:38 -0400 From: Lukas Berk To: Marko Myllynen Cc: pcp developers Subject: Re: [pcp] [PATCH] pcp-webjs has moved, update URLs References: <5549F6AA.8090506@redhat.com> <87vbg5v6gt.fsf@redhat.com> <554B07E4.1040005@redhat.com> X-ASG-Orig-Subj: Re: [pcp] [PATCH] pcp-webjs has moved, update URLs Date: Thu, 07 May 2015 11:15:37 -0400 In-Reply-To: <554B07E4.1040005@redhat.com> (Marko Myllynen's message of "Thu, 07 May 2015 09:36:20 +0300") Message-ID: <87a8xgl8py.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1431011739 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hey, Marko Myllynen writes: > On 2015-05-06 22:41, Lukas Berk wrote: >> Marko Myllynen writes: >> [...] >>> -

The applications in the >> HREF="http://git.pcp.io/cgi-bin/gitweb.cgi?p=pcp-webjs.git">pcp-webjs >>> source tree are helpful when developing new web applications.

>>> +

The applications in the >> HREF="https://github.com/performancecopilot/pcp-webjs">pcp-webjs >>> source tree are helpful when developing new web applications.

>> [...] >>> - git clone git://git.pcp.io/pcp-webjs.git pcp-webjs >>> + git clone https://github.com/performancecopilot/pcp-webjs pcp-webjs >> >> I believe the most up to date location would actually be >> git://sourceware.org/git/pcpfans.git webjs > I'm ok either way as long as they both work, > https://sourceware.org/git/pcpfans.git/ currently gives "Forbidden" so > that's why I chose github for both cases. Aha, if you're looking for the gitweb, it's hosted here: https://www.sourceware.org/git/gitweb.cgi?p=pcpfans.git;a=shortlog;h=refs/heads/webjs I believe upstream pcp.git/scripts/spin-rawhide already uses the sourceware.org git location for pcp-webjs so no need to tweak that. Thanks for being open to this using route! Cheers, Lukas From lberk@redhat.com Thu May 7 12:40:03 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id E62D97F37 for ; Thu, 7 May 2015 12:40:02 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 83A19AC002 for ; Thu, 7 May 2015 10:39:59 -0700 (PDT) X-ASG-Debug-ID: 1431020394-04cb6c1cc75811d0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id A93JkRrlSMffRu1h (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 10:39:55 -0700 (PDT) X-Barracuda-Envelope-From: lberk@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t47HdqMD013469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 7 May 2015 13:39:52 -0400 Received: from toium (unused-10-15-17-202.yyz.redhat.com [10.15.17.202]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t47Hdp3g013669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 May 2015 13:39:52 -0400 From: Lukas Berk To: Mark Goodwin Cc: pcp@oss.sgi.com Subject: Re: [pcp] [RFC] Minimizing Installation Size for Reduced PCP Footprint References: <87bnk0wzn5.fsf@redhat.com> <877ft59dmo.fsf@redhat.com> <1565443824.10833179.1430459606977.JavaMail.zimbra@redhat.com> <87383c19uy.fsf@redhat.com> <554843FC.9040109@redhat.com> <87d22eyfut.fsf@redhat.com> <55496FC7.8060600@gmail.com> <874mnpjs3u.fsf@redhat.com> <554AD069.9060106@redhat.com> <554AFCE0.9010606@gmail.com> X-ASG-Orig-Subj: Re: [pcp] [RFC] Minimizing Installation Size for Reduced PCP Footprint Date: Thu, 07 May 2015 13:39:51 -0400 In-Reply-To: <554AFCE0.9010606@gmail.com> (Mark Goodwin's message of "Thu, 07 May 2015 15:49:20 +1000") Message-ID: <87mw1g1e3c.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1431020395 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hey, Mark Goodwin writes: [...] > Lukas, what's the plan for deb packaging, and the fedora SPEC? Now that the changes are merged, the plan is to start moving them over to fedora.spec and debian packaging respectively. I'll have to switch the compat conditionals in the deb packaging such that it achieves the same requirement on already released distros. For the fedora.spec, it would probably be wise to run rpmlint over the new spec file (something Nathan hinted to me earlier). So I'll be doing that as well and keeping the output in mind when submitting those changes on list. Any other thoughts on potential gotcha's are (as always) greatly appreciated. Thanks again for your thoughts and review! Cheers, Lukas From lberk@redhat.com Thu May 7 14:50:07 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 0DED87F37 for ; Thu, 7 May 2015 14:50:07 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 9F120AC003 for ; Thu, 7 May 2015 12:50:03 -0700 (PDT) X-ASG-Debug-ID: 1431028198-04bdf063225f3040001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 5Eh2OWrGCR76Sp3z (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 12:49:59 -0700 (PDT) X-Barracuda-Envelope-From: lberk@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t47JnwlM021150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 7 May 2015 15:49:58 -0400 Received: from toium (unused-10-15-17-202.yyz.redhat.com [10.15.17.202]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t47JnvIf002451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 7 May 2015 15:49:58 -0400 From: Lukas Berk To: pcp@oss.sgi.com Subject: PCP Buidbot and Improving QA Date: Thu, 07 May 2015 15:49:57 -0400 X-ASG-Orig-Subj: PCP Buidbot and Improving QA Message-ID: <871tisgobe.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1431028199 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hey Folks, I wanted to share something I've set up, to try to help ease and distribute the quality assurance responsibility among the PCP community. Despite the fact PCP ships on a variety of distros and operating systems, my understanding is that only a few core devs actually test the changes on a variety of platforms with any amount of frequency. http://buildbot.pcp.io is my attempt to change this, and at the same time, create more transparency among the community for the current shape of the testsuite. The most relevant page to developers will be http://buildbot.pcp.io/waterfall . There you can see the latest test results. Buildbot offers a distrbuted, modular, design. Meaning; individuals can contribute the flavour of buildslave(s) (the machines doing the actual testing) which matter the most to them. As an example, I do most of my work on a fedora, and am more comfortable administering and monitoring the state for QA purposes. So I've contributed Fedora 20 and 21 buildslaves. Conversely, I'm not as focused on ubuntu or debian distros, but individuals who are (and use PCP on such platforms) can contribute buildslaves of that variety. Thus, increasing the chances there are no breaking changes that I (or somebody else) has caused and failed to catch. This takes the load off any single person to maintain all the platforms we ship on. Currently I have the buildbot setup to watch merges to the master branch, and it tests the set of commits pushed upstream within a one minute span. This allows us to keep track how a specific set of commits effect the testsuite with greater accuracy. An example would be one of the latest builds ( http://buildbot.pcp.io/builders/fedora/builds/78 ), which has changes from both Ken and Martins. You can see the steps taken to build this revision, and full testsuite results ( http://buildbot.pcp.io/builders/fedora/builds/78/steps/Run%20Testsuite/logs/stdio ). I've written several helper scripts for setting up a buildslave, and the master.cfg being used on buildbot.pcp.io for those interested on git://sourceware.org/git/pcpfans.git lberk/buildbot They're located in the qa/buildbot dir. If these changes could get merged upstream, I would appreciate it. I've written further documentation on how to setup a buildslave at http://pcp.io/buildbot.html Please let me know if anything requires clarification, or additional steps (I'm sure I've probably missed something). If the community as a whole is interested in pursuing and using a buildbot, I'm happy to continue running the buildmaster. In that case, I would humbly ask for those interested to help, setup testing environments (buildslaves) for the following distros; Debian Ubuntu Solaris MacOSX CentOS/RHEL OpenSuse The more variety of architectures the better as well. I Would also need a list of instructions (a recipe if you will) of each step needed to: 1. build pcp (./Makepgks) 2. Uninstall any previous PCP on themachine/vm with the package manager, but not the dependencies 3. Install the freshly baked PCP 4. start/enable the required services 5. run the testsuite An example can be found in the qa/buildbot/master.cfg file for how I've done so with fedora. Several questions moving forwards: 1. What should constitute a 'failed' testsuite run? Currently on my fedora buildslaves, I'm at 11 failures (which I know is too high). However, is always having 0 failures too noisy for those administering the buildslaves? Should we set a threshold slightly higher than that? Should it simply be considered a failure when there is an increase comparatively to the last run? (not sure how easy/possible that is to setup) Likewise, I need to lower the number of [notrun] tests I currently have on those machines. 2. How should we report (new) failures? Do we want to at all? Should it just be an the website for devs to check? Buildbot is capable of running an irc bot to inform those one the #pcp channel. However I know not everybody uses irc. 3. Do we want warnings if the ./Makepkgs process has any 'Warnings' in the output (such as unused vars, etc)? 4. I'm all out of questions, what questions are there for me? Concerns? Hope this ends up being useful. Cheers, Lukas From fche@redhat.com Thu May 7 15:27:52 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 6F4347F37 for ; Thu, 7 May 2015 15:27:52 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 080EEAC003 for ; Thu, 7 May 2015 13:27:48 -0700 (PDT) X-ASG-Debug-ID: 1431030463-04cb6c1cc85874a0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id iyhQ9XOSK2RHiC0o (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 13:27:44 -0700 (PDT) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t47KRfrQ010894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 7 May 2015 16:27:41 -0400 Received: from fche.csb (vpn-226-104.phx2.redhat.com [10.3.226.104]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t47KRfY1003409; Thu, 7 May 2015 16:27:41 -0400 Received: by fche.csb (Postfix, from userid 2569) id 5173E585D6; Thu, 7 May 2015 16:27:39 -0400 (EDT) To: Martins Innus Cc: pcp Subject: Re: PCP Grafana questions References: <554A7198.10509@buffalo.edu> X-ASG-Orig-Subj: Re: PCP Grafana questions From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 07 May 2015 16:27:39 -0400 In-Reply-To: <554A7198.10509@buffalo.edu> (Martins Innus's message of "Wed, 06 May 2015 15:55:04 -0400") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1431030463 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 minnus wrote: > I'm starting to mess with the various pcp-webjs options and have > a few questions on using the grafana component. [...] Very good, thanks for your interest.. > [...] > Not sure what they are called, but for lack of a better name I > can't get the "metric operations" to work [...] Yes, this is documented in pmwebapi(3) and http://oss.sgi.com/bugzilla/show_bug.cgi?id=1094 . > 2. > My test case is about 1 month worth of a single node's archives with > ~200 metrics collected at 30 sec intervals (3 GB), roughly 1 file > per day, ~30 files. [...] When editing the metrics it takes a while > for the field to populate. [...] but it would be great to get some > feedback that something is happening. [...] We ship generally -unmodified- webapps, so if the normal graphite/grafana webapp doesn't have a 'please wait ...' kind of blinkenlight, it's not there in the pcp-webjs copy either. > 3. > > I am starting to do my own testing, but has anybody done scalability > studies? My largest dimension is going to be number of hosts. So is > it reasonable that I could plot ~5 metrics over a day but across 100 > host archives? 1000 host archives? [...] The largest views I've handled involved some dozens of hosts (split over some hundreds of time-sliced archives). With the pmwebd -M (multithreaded mode), it's behaved reasonably quickly; make sure you're on pcp 3.10.4. How well it scales is also a function of the web browser - so try the "png" (server-side) as well as "flot" (browser-side) rendering options. - FChE From fche@redhat.com Thu May 7 15:36:04 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 563C97F37 for ; Thu, 7 May 2015 15:36:04 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id E6485AC005 for ; Thu, 7 May 2015 13:36:03 -0700 (PDT) X-ASG-Debug-ID: 1431030962-04bdf063205f4e20001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 50qe1yLzZnnf6Ebe (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 13:36:03 -0700 (PDT) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t47KZlpZ014325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 7 May 2015 16:35:47 -0400 Received: from fche.csb (vpn-226-104.phx2.redhat.com [10.3.226.104]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t47KZlTQ016156; Thu, 7 May 2015 16:35:47 -0400 Received: by fche.csb (Postfix, from userid 2569) id 4F139585D6; Thu, 7 May 2015 16:35:45 -0400 (EDT) To: Ken McDonell Cc: pcp@oss.sgi.com Subject: Re: Calculated/derived metrics? References: <5534C680.2020709@redhat.com> <493537984.3276058.1429528962326.JavaMail.zimbra@redhat.com> <5534EBA8.4030509@redhat.com> <1644393599.3651017.1429563442835.JavaMail.zimbra@redhat.com> <55364606.1000503@redhat.com> <55472B40.7050800@redhat.com> <5547DE11.5050800@internode.on.net> <5549E4CD.5000408@redhat.com> <554AFE4E.80000@internode.on.net> X-ASG-Orig-Subj: Re: Calculated/derived metrics? From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 07 May 2015 16:35:45 -0400 In-Reply-To: <554AFE4E.80000@internode.on.net> (Ken McDonell's message of "Thu, 07 May 2015 15:55:26 +1000") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1431030962 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 kenj wrote: > [...] >> [...] For example, I tried to derive the bytes-written/s for a >> process being monitored with hotproc. A process' lifetime can roughly be >> calculated with kernel uptime - the process' start_time / 100. But >> testing with something like: >> >> write_per_sec = hotproc.io.write_bytes / (kernel.all.uptime - >> hotproc.psinfo.start_time/100) >> >> leads to an (expected) error as there are several instances. ... > [...] > The problem in your example is that the expression involves the > counter hotproc.io.write_bytes and this is being divided by > something with the units of time that is not a counter. [...] Is the rate() derived-metrics function applicable here? - FChE From dsmith@redhat.com Thu May 7 16:05:21 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 791377F37 for ; Thu, 7 May 2015 16:05:21 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 0B0AFAC001 for ; Thu, 7 May 2015 14:05:17 -0700 (PDT) X-ASG-Debug-ID: 1431032716-04bdf063205f5f50001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Rp88vFmApdfoDDgy (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 14:05:17 -0700 (PDT) X-Barracuda-Envelope-From: dsmith@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t47L5GHo021990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 7 May 2015 17:05:16 -0400 Received: from t540p.usersys.redhat.com (dhcp-10-15-1-2.hsv.redhat.com [10.15.1.2]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t47L5F4f030330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 May 2015 17:05:15 -0400 Message-ID: <554BD38B.4060300@redhat.com> Date: Thu, 07 May 2015 16:05:15 -0500 From: David Smith User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Nathan Scott CC: pcp Subject: Re: [pcp] JSON PMDA References: <54F9F92D.4010202@redhat.com> <552699FE.7040801@redhat.com> <2139482617.15593599.1428634701360.JavaMail.zimbra@redhat.com> <552D6524.1030803@redhat.com> <1237712965.18667183.1429054767135.JavaMail.zimbra@redhat.com> <5536C228.8010001@redhat.com> <1344441557.4430503.1429658863072.JavaMail.zimbra@redhat.com> <55493338.3050609@redhat.com> <422876605.13652980.1430893026406.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] JSON PMDA In-Reply-To: <422876605.13652980.1430893026406.JavaMail.zimbra@redhat.com> Content-Type: multipart/mixed; boundary="------------080704020705060003010500" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1431032717 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 This is a multi-part message in MIME format. --------------080704020705060003010500 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 05/06/2015 01:17 AM, Nathan Scott wrote: > Hi David, > > ----- Original Message ----- >> [...] >> OK, here's a quite rough patch that makes the needed changes to cache.c >> (and associated files), and then modifies the JSON PMDA to use indom >> caches for cluster and metric assignments. There are several "FIXME" >> comments scattered throughout the changes, and more code will need to be >> added to pmda.py to make this more user-friendly. But, it does seem to >> work in the limited testing I've done. >> > > Ah excellent, sounds promising. > > + > + if (maximum < 0) > + return PM_ERR_SIGN; > + // FIXME: What do we do if there is already something in the cache > + // with an instance greater than the new maximum? > > Possibly return PM_ERR_TOOBIG or PM_ERR_TOOSMALL for this case? > > + // FIXME 2: Does this maximum value need to be saved/restored when > + // the cache itself is saved/restored? Currently only a few things > + // from the header are stored. > + h->maxinst = maximum; > > Yep, I believe so - see Ken's note below, third paragraph... > http://www.pcp.io/pipermail/pcp/2015-April/006982.html This patch is cleaned up a good bit. I fixed the above items and made several changes to pmda.py. I've got a question about the "exports" file, which I've never messed with before. Should I have put the new function at the end of the list? Do I need to define a new library version? I've got a "philosophy" question about the pmda itself. Originally, each array had its own indom cache. For this new version, I've switched to one indom cache per JSON source (each JSON source is also in its own cluster). I think I can see a way to switch back to the original method (by adding another cache that maps cache numbers back to arrays), but I wasn't sure which way was more "correct". -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) --------------080704020705060003010500 Content-Type: text/x-patch; name="cache_change2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cache_change2.patch" diff --git a/src/include/pcp/pmda.h b/src/include/pcp/pmda.h index 20968f1..654269b 100644 --- a/src/include/pcp/pmda.h +++ b/src/include/pcp/pmda.h @@ -592,6 +592,9 @@ extern pmnsNode * pmdaNodeLookup(pmnsNode *, const char *); * * pmdaCachePurge * cull inactive entries + * + * pmdaCacheResize + * set the maximum instance identifier */ extern int pmdaCacheStore(pmInDom, int, const char *, void *); extern int pmdaCacheStoreKey(pmInDom, int, const char *, int, const void *, void *); @@ -600,6 +603,7 @@ extern int pmdaCacheLookupName(pmInDom, const char *, int *, void **); extern int pmdaCacheLookupKey(pmInDom, const char *, int, const void *, char **, int *, void **); extern int pmdaCacheOp(pmInDom, int); extern int pmdaCachePurge(pmInDom, time_t); +extern int pmdaCacheResize(pmInDom, int); #define PMDA_CACHE_LOAD 1 #define PMDA_CACHE_ADD 2 diff --git a/src/libpcp_pmda/src/cache.c b/src/libpcp_pmda/src/cache.c index dd74b3f..37feda6 100644 --- a/src/libpcp_pmda/src/cache.c +++ b/src/libpcp_pmda/src/cache.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013 Red Hat. + * Copyright (c) 2013,2015 Red Hat. * Copyright (c) 2005 Silicon Graphics, Inc. All Rights Reserved. * * This library is free software; you can redistribute it and/or modify it @@ -39,7 +39,9 @@ typedef struct entry { time_t stamp; } entry_t; -#define VERSION 1 /* version of external file format */ +#define CACHE_VERSION1 1 +#define CACHE_VERSION2 2 +#define CACHE_VERSION CACHE_VERSION2 /* version of external file format */ #define MAX_HASH_TRY 10 /* @@ -59,8 +61,11 @@ typedef struct hdr { int ins_mode; /* see insert_cache() */ int hstate; /* dirty/clean/string state */ int keyhash_cnt[MAX_HASH_TRY]; + int maxinst; /* maximum inst */ } hdr_t; +#define DEFAULT_MAXINST 0x7fffffff + /* bitfields for hstate */ #define DIRTY_INSTANCE 0x1 #define DIRTY_STAMP 0x2 @@ -189,6 +194,7 @@ find_cache(pmInDom indom, int *sts) h->hstate = 0; for (i = 0; i < MAX_HASH_TRY; i++) h->keyhash_cnt[i] = 0; + h->maxinst = DEFAULT_MAXINST; return h; } @@ -617,7 +623,7 @@ insert_cache(hdr_t *h, const char *name, int inst, int *sts) if (last_e == NULL) inst = 0; else { - if (last_e->inst == 0x7fffffff) { + if (last_e->inst == h->maxinst) { /* * overflowed inst identifier, need to shift to * ins_mode == 1 @@ -635,7 +641,7 @@ retry: for (e = h->first; e != NULL; e = e->next) { if (inst < e->inst) break; - if (inst == 0x7fffffff) { + if (inst == h->maxinst) { /* * 2^32-1 is the maximum number of instances we can have */ @@ -742,10 +748,34 @@ load_cache(hdr_t *h) fclose(fp); return PM_ERR_GENERIC; } - s = sscanf(buf, "%d %d", &x, &h->ins_mode); - if (s != 2 || x != 1 || h->ins_mode < 0 || h->ins_mode > 1) { + /* First grab the file version. */ + s = sscanf(buf, "%d ", &x); + if (s != 1 || x <= 0 || x > CACHE_VERSION) { __pmNotifyErr(LOG_ERR, - "pmdaCacheOp: %s: illegal first record: %s", + "pmdaCacheOp: %s: illegal cache header record: %s", + filename, buf); + fclose(fp); + return PM_ERR_GENERIC; + } + + /* Based on the file version, grab the entire line. */ + switch (x) { + case CACHE_VERSION1: + h->maxinst = DEFAULT_MAXINST; + s = sscanf(buf, "%d %d", &x, &h->ins_mode); + if (s != 2) + s = 0; + break; + default: + s = sscanf(buf, "%d %d %d", &x, &h->ins_mode, &h->maxinst); + if (s != 3) + s = 0; + break; + } + if (s == 0 || h->ins_mode < 0 || h->ins_mode > 1 || h->maxinst < 0 + || h->maxinst > DEFAULT_MAXINST) { + __pmNotifyErr(LOG_ERR, + "pmdaCacheOp: %s: illegal cache header record: %s", filename, buf); fclose(fp); return PM_ERR_GENERIC; @@ -873,7 +903,7 @@ save_cache(hdr_t *h, int hstate) vdp, sep, sep, sep, pmInDomStr_r(h->indom, strbuf, sizeof(strbuf))); if ((fp = fopen(filename, "w")) == NULL) return -oserror(); - fprintf(fp, "%d %d\n", VERSION, h->ins_mode); + fprintf(fp, "%d %d %d\n", CACHE_VERSION, h->ins_mode, h->maxinst); now = time(NULL); cnt = 0; @@ -1411,6 +1441,35 @@ int pmdaCachePurge(pmInDom indom, time_t recent) return cnt; } +int pmdaCacheResize(pmInDom indom, int maximum) +{ + hdr_t *h; + int sts; + entry_t *e; + + if (indom == PM_INDOM_NULL) + return PM_ERR_INDOM; + + if ((h = find_cache(indom, &sts)) == NULL) + return sts; + + if (maximum < 0) + return PM_ERR_SIGN; + + /* Find the largest inst in the queue. */ + for (e = h->first; e != NULL; e = e->next) { + /* If the new maximum is smaller than an existing inst, error. */ + if (maximum < e->inst) + return PM_ERR_TOOBIG; + } + + // FIXME 2: Does this maximum value need to be saved/restored when + // the cache itself is saved/restored? Currently only a few things + // from the header are stored. + h->maxinst = maximum; + return 0; +} + /* -------------------------------------------------------------------- lookup2.c, by Bob Jenkins, December 1996, Public Domain. diff --git a/src/libpcp_pmda/src/exports b/src/libpcp_pmda/src/exports index 323d8f6..f5fc5c2 100644 --- a/src/libpcp_pmda/src/exports +++ b/src/libpcp_pmda/src/exports @@ -119,6 +119,8 @@ PCP_PMDA_3.4 { pmdaInterfaceMoved; pmdaNodeLookup; + pmdaCacheResize; + pmdaRootConnect; pmdaRootShutdown; pmdaRootContainerHostName; diff --git a/src/pmdas/json/pmdajson.python b/src/pmdas/json/pmdajson.python index a9b59a3..959fcff 100644 --- a/src/pmdas/json/pmdajson.python +++ b/src/pmdas/json/pmdajson.python @@ -9,7 +9,7 @@ from collections import OrderedDict from pcp.pmda import PMDA, pmdaMetric, pmdaIndom import cpmapi as c_api from pcp.pmapi import pmUnits, pmContext, pmErr -from ctypes import c_int, POINTER, cast +from ctypes import c_int import os, stat, pwd import re import traceback @@ -17,7 +17,8 @@ import subprocess import shlex MAX_CLUSTER = 0xfff # 12 bits, see pcp/impl.h -MAX_ITEM = 0x3ff # 10 bits, see pcp/impl.h +MAX_METRIC = 0x3ff # 10 bits, see pcp/impl.h +MAX_INDOM = 0x7fffffff NOBODY_UID = -1 NOBODY_GID = -1 @@ -33,12 +34,12 @@ def preexec(): class Metric(object): ''' Metric information class ''' __name_re = re.compile(r'^[a-zA-Z][\w_\.]+$') - def __init__(self, name_prefix, cluster, idx, pmda): + def __init__(self, name_prefix, cluster, pmda): self.__name = '' self.name_prefix = name_prefix self.full_name = '' self.cluster = cluster - self.idx = idx + self.idx = -1 self.__pmda = pmda self.desc = '' self.type = c_api.PM_TYPE_UNKNOWN @@ -46,7 +47,7 @@ class Metric(object): self.pointer = None self.pmid = None self.obj = None - self.indom = None + self.indom_cache = None self.index_pointer = None self.__units_val = pmUnits(0, 0, 0, 0, 0, 0) self.__units_str = '' @@ -109,8 +110,8 @@ class Metric(object): raise RuntimeError("Invalid metric") self.pmid = self.__pmda.pmid(self.cluster, self.idx) - if self.indom != None: - self.obj = pmdaMetric(self.pmid, self.type, self.indom.obj, + if self.indom_cache != None: + self.obj = pmdaMetric(self.pmid, self.type, self.indom_cache.indom, self.sem, self.__units_val) else: self.obj = pmdaMetric(self.pmid, self.type, c_api.PM_INDOM_NULL, @@ -119,45 +120,125 @@ class Metric(object): # Note that you can't delete individual metrics. The # pmda.{clear,reset}_metrics() functions clear out *all* metrics. -class Indom(object): - ''' Indom (instance domain) information class ''' - def __init__(self, idx, pmda): +class IndomCache(pmdaIndom): + ''' Indom (instance domain) cache information class ''' + def __init__(self, serial, max_value, pmda): self.__pmda = pmda - self.idx = idx - self.obj = pmda.indom(self.idx) - self.values = {} - self.__pmda.add_indom(pmdaIndom(self.obj, self.values)) + self.serial = serial + + # In IndomCache.add_value, we're using 'value' as the inst + # value. However, the pmdaCache routines treat the passed in + # value as the 'private' field and generates its own inst + # value. However, this 'private' field isn't saved and + # restored, so it isn't very useful for our purposes. + # + # To get around this, we'll use an OrderedDict so that the + # dictionary order should match up with the inst order. + # (Another way to fix this problem would be to go ahead and + # call pmdaCacheStore() in IndomCache.add_value(), but that + # fix would require more api calls.) + self.__values = OrderedDict() + # '__names_by_values' is the inversion of '__values'. + self.__names_by_values = {} + pmdaIndom.__init__(self, pmda.indom(self.serial), self.__values) + try: + self.__pmda.add_indom(self) + except KeyError: + # If we've seen this indom before, it will already be + # present in the pmda, so replace it. + self.__pmda.replace_indom(self, self.__values) + self.__maxval = max_value + self.cache_resize(max_value) + self.__nextval = 0 + + @property + def indom(self): + ''' Get cache's indom. ''' + return self.it_indom def log(self, string): ''' Log an informational message ''' return self.__pmda.log(string) - def add_value(self, name, value): + def add_value(self, name, value=c_api.PM_IN_NULL): ''' Add a value to the indom ''' # PMDA.replace_indom() wants a dictionary, indexed by # indom string value. PMDA.replace_indom() doesn't really # care what is stored at that string value. We're storing the - # array index there. - self.values[name] = c_int(value) + # instance there. + if value == c_api.PM_IN_NULL: + value = self.next_value() + if self.__pmda.debug: + self.log("Adding ('%s', %d) to the cache" % (name, value)) + self.__values[name] = c_int(value) + if value >= self.__nextval: + self.__nextval = value + 1 + self.__names_by_values[value] = name + + def lookup_name(self, name): + ''' + Lookup name in an indom cache and return its associated value. + ''' + if name not in self.__values: + raise KeyError(name) + valueobj = self.__values[name] + return valueobj.value - def lookup_inst(self, inst): - ''' Lookup an array index based on the instance ID ''' - voidp = self.__pmda.inst_lookup(self.obj, inst) - if voidp == None: - return None - valuep = cast(voidp, POINTER(c_int)) - return valuep.contents.value + def lookup_value(self, value): + ''' + Lookup a value in an indom cache and return its associated name. + ''' + # We could call an api function here (pmda.inst_lookup() which + # calls pmdaCacheLookup()), but we can handle this in python + # by using the inverted dictionary. + if value not in self.__names_by_values: + raise KeyError(value) + return self.__names_by_values[value] + + def refresh(self): + ''' Update and save the indom cache. ''' + self.__pmda.replace_indom(self, self.__values) + # Note that set_dict_instances() saves the cache to disk. + self.set_dict_instances(self.it_indom, self.__values) + + def load(self): + ''' Load indom cache values. ''' + if self.__pmda.debug: + self.log("Loading cache %d..." % self.serial) + pmdaIndom.load(self) + self.cache_active() + for (inst, name) in self: + self.add_value(name, inst) + + def next_value(self): + ''' Return next value to be allocated. ''' + if self.__nextval > self.__maxval: + raise ValueError("Indom cache reached max value.") + value = self.__nextval + self.__nextval += 1 + return value + + def len(self): + ''' Return cache size. ''' + return len(self.__values) class JsonSource(object): ''' JSON Source class. Contains all metrics and data needed by a single JSON source. ''' - def __init__(self, path, cluster, pmda, trusted): + def __init__(self, path, pmda, trusted): self.__path = path - self.cluster = cluster self.__pmda = pmda + # cluster, metric_cache_idx, and indom_cache_idx get filled in later. + self.__cluster = -1 + self.__metric_cache_idx = -1 + self.__indom_cache_idx = -1 + self.__metric_cache = None + self.__indom_cache = None + self.__array_indexes = {} + # Note that this is the default root name. It can be # overridden with the metadata 'prefix' attribute. self.__root_name = os.path.basename(path) @@ -184,14 +265,58 @@ class JsonSource(object): self.__json_data = {} self.__metrics = {} self.__metrics_by_name = {} - self.__metric_idx = 0 - self.__indoms = {} self.__lastfetch = 0 + # Here we need to load the metadata and preparse it, in case + # it changes the source name. + self.__load_json_metadata() + self.__preparse_metadata() + def log(self, string): ''' Log an informational message ''' return self.__pmda.log(string) + @property + def name(self): + ''' + Get JSON source name value. This defaults to the base name of + the directory where the JSON source was found, but can be + overridden by the metadata file. + ''' + return self.__root_name + + @property + def cluster(self): + ''' Returns the source's cluster id. ''' + return self.__cluster + + @cluster.setter + def cluster(self, cluster): + ''' Sets the source's cluster id. ''' + self.__cluster = cluster + # Note that the cache indexes are laid out like this: + # 0: cluster cache (cluster 0 is for the static metrics, + # cluster 1 is for the first JSON source) + # 1: metric cache for JSON source #1 + # 2: indom cache for JSON source #1 + # 3: metric cache for JSON source #2 + # 4: indom cache for JSON source #2 + # 5: metric cache for JSON source #3 + # 6: indom cache for JSON source #3 + # ... + + self.__metric_cache_idx = (self.__cluster * 2) - 1 + self.__indom_cache_idx = self.__metric_cache_idx + 1 + # Now that we know the cluster id, try to load the metric + # cache and indom cache. Note that if they aren't present, + # that's OK - this must be a new JSON source. + self.__metric_cache = IndomCache(self.__metric_cache_idx, + MAX_METRIC, self.__pmda) + self.__metric_cache.load() + self.__indom_cache = IndomCache(self.__indom_cache_idx, + MAX_INDOM, self.__pmda) + self.__indom_cache.load() + def __load_json_metadata(self): ''' Load the JSON metadata file for this JSON source. ''' self.__metadata = {} @@ -255,7 +380,8 @@ class JsonSource(object): % self.__data_exec) self.log("%s" % traceback.format_exc()) else: - self.log("Found data-path %s" % self.__data_path) + if self.__pmda.debug: + self.log("Found data-path %s" % self.__data_path) try: fobj = open(self.__data_path) except IOError: @@ -278,8 +404,8 @@ class JsonSource(object): ''' if self.__pmda.debug: self.log("Loading JSON source %s" % self.__root_name) - self.__load_json_metadata() - self.__preparse_metadata() + # Note that we're loading the metadata in the init function, + # so we can update the source name. self.__load_json_data() # If either loading the metadata or data failed, quit. @@ -314,25 +440,36 @@ class JsonSource(object): def __refresh_indoms(self): ''' Refresh the list of indoms. ''' # Notice we never delete indoms, we just keep adding. - for array_name in self.__indoms.keys(): - index = 0 + self.__array_indexes.clear() + for (dummy, metric_info) in self.__metrics.iteritems(): + # Skip non-arrays. + if metric_info.index_pointer == None: + continue + try: - metric_info = self.__metrics_by_name[array_name] metrics_array = metric_info.pointer.resolve(self.__json_data) - # Loop through all the array items, updating the indom - # list with the array's index pointer values. + # list with any new values. Also remember the array + # index where we found a particular indom, to make + # retrieval easy. + index = 0 for item in metrics_array: indom_value = metric_info.index_pointer.resolve(item) - self.__indoms[array_name].add_value(indom_value, index) + full_name = "%s.%s" % (metric_info.name, indom_value) + self.__array_indexes[full_name] = index index += 1 + try: + dummy = self.__indom_cache.lookup_name(indom_value) + except KeyError: + # This indom value wasn't found in the indom + # cache. Add it. + self.__indom_cache.add_value(indom_value) except KeyError: self.log("Error while refreshing indom for array %s" - % array_name) + % metric_info.name) self.log("%s" % traceback.format_exc()) continue - self.__pmda.replace_indom(self.__indoms[array_name].obj, - self.__indoms[array_name].values) + self.__indom_cache.refresh() def __add_metric(self, metric_info): ''' Create and add a metric to the pmda. ''' @@ -346,26 +483,11 @@ class JsonSource(object): def __parse_array_metadata(self, array_name, metrics_array): ''' Parse a JSON array metadata. ''' - if array_name not in self.__indoms: - # Note that we're creating an indom here, but we don't - # know any values for it yet. We'll get those on a data - # read. - self.__indoms[array_name] = Indom(self.__pmda.indom_idx, - self.__pmda) - self.__pmda.indom_idx += 1 - # Process the array's metrics array. metric_prefix = "%s.%s" % (self.__pmda.pmda_name, self.__root_name) for item in metrics_array: - if self.__metric_idx > MAX_ITEM: - self.log("Skipping metrics in '%s' - max metric reached" - % metric_prefix) - break - metric_info = Metric(metric_prefix, self.cluster, - self.__metric_idx, self.__pmda) - self.__metric_idx += 1 - metric_info.indom = self.__indoms[array_name] - + metric_info = Metric(metric_prefix, self.cluster, self.__pmda) + metric_info.indom_cache = self.__indom_cache error_seen = 0 for (key, value) in item.iteritems(): # 'name' (required): Sanity check it and save it. @@ -380,7 +502,7 @@ class JsonSource(object): # this metric self.log("Skipping metric with invalid name '%s.%s'" % (array_name, value)) - break + continue # 'type' (required): Sanity check it and save it. elif key == 'type': if not isinstance(value, unicode): @@ -427,6 +549,23 @@ class JsonSource(object): self.log("Ignoring unknown attribute in metadata '%s'" % (key)) + # Try looking up the metric name in the metric cache. If + # it is there, reuse the metric index. + try: + metric_info.idx \ + = self.__metric_cache.lookup_name(metric_info.name) + except KeyError: + try: + # We couldn't find the metric name, so just grab + # the next metric index value. + metric_info.idx = self.__metric_cache.next_value() + self.__metric_cache.add_value(metric_info.name, + metric_info.idx) + except ValueError: + self.log("Skipping metrics in '%s' - max metric reached" + % metric_prefix) + break + # Make sure we have everything we need. If not (or we've # seen an error), just skip this metric. if error_seen or not metric_info.valid() \ @@ -435,9 +574,12 @@ class JsonSource(object): self.log("Metadata doesn't have required" " information for the following entry: %s" % metric_info.name) + del metric_info continue # We have all the required information. Add the metric. + if self.__pmda.debug: + self.log("Adding metric '%s'" % metric_info.name) self.__add_metric(metric_info) def __preparse_metadata(self): @@ -481,6 +623,11 @@ class JsonSource(object): Go through the meta, looking for information we can use to create the pcp representation of the metadata. ''' + # Make sure we've got a real cluster idx at this point. + if self.__cluster < 0: + raise TypeError("Cluster index must be set before parsing" + " metadata to create metrics.") + # Look for the "metrics" array. metrics_array = None for (key, value) in self.__metadata.items(): @@ -508,14 +655,7 @@ class JsonSource(object): # Process the metrics array. metric_prefix = "%s.%s" % (self.__pmda.pmda_name, self.__root_name) for item in metrics_array: - if self.__metric_idx > MAX_ITEM: - self.log("Skipping metrics in '%s' - max metric reached" - % metric_prefix) - break - metric_info = Metric(metric_prefix, self.cluster, - self.__metric_idx, self.__pmda) - self.__metric_idx += 1 - + metric_info = Metric(metric_prefix, self.__cluster, self.__pmda) error_seen = 0 for (key, value) in item.iteritems(): # 'name' (required): Sanity check it and save it. @@ -533,7 +673,7 @@ class JsonSource(object): self.log("Skipping metric with invalid name '%s'" % value) error_seen = 1 - break + continue # 'type' (required): Sanity check it and save it. elif key == 'type': if not isinstance(value, unicode): @@ -615,6 +755,23 @@ class JsonSource(object): self.log("Ignoring unknown attribute in metadata '%s'" % (key)) + # Try looking up the metric name in the metric cache. If + # it is there, reuse the metric index. + try: + metric_info.idx \ + = self.__metric_cache.lookup_name(metric_info.name) + except KeyError: + try: + # We couldn't find the metric name, so just grab + # the next metric index value. + metric_info.idx = self.__metric_cache.next_value() + self.__metric_cache.add_value(metric_info.name, + metric_info.idx) + except ValueError: + self.log("Skipping metrics in '%s' - max metric reached" + % metric_prefix) + break + # Make sure we have everything we need. If not (or we've # seen an error), just skip this metric. if error_seen or not metric_info.valid() \ @@ -629,6 +786,8 @@ class JsonSource(object): if self.__pmda.debug: self.log("Adding metric '%s'" % metric_info.name) self.__add_metric(metric_info) + # Now that all the metrics are created, save the metric cache. + self.__metric_cache.refresh() def fetch(self, item, inst): ''' Fetch value for this item and instance. ''' @@ -643,14 +802,7 @@ class JsonSource(object): metric_info = self.__metrics[item] # Handle array metrics. - if metric_info.indom != None: - # Get the array index from the indom. - array_index = metric_info.indom.lookup_inst(inst) - if array_index == None: - self.log("JSON source %s has no indom %d" - % (self.__root_name, inst)) - return [c_api.PM_ERR_INST, 0] - + if metric_info.indom_cache != None: # Split the full name into the array name and metric (array, dummy) = metric_info.name.split('.', 2) if array not in self.__metrics_by_name: @@ -663,9 +815,18 @@ class JsonSource(object): # Get the entire array. metrics_array = array_info.pointer.resolve(self.__json_data) - # Get the appropriate item from within the desired array entry. - return [metric_info.pointer.resolve(metrics_array[array_index]), - 1] + # Turn the instance id into a name. + name = self.__indom_cache.lookup_value(inst) + + # Using that name, lookup the array index where we + # found it. + full_name = "%s.%s" % (array_info.name, name) + try: + index = self.__array_indexes[full_name] + except KeyError: + self.log("array index for '%s' cannot be found" % full_name) + return [c_api.PM_ERR_INDOM, 0] + return [metric_info.pointer.resolve(metrics_array[index]), 1] except (KeyError, TypeError): self.log("Error while fetching metrics for array %s" % array_info.name) @@ -695,18 +856,31 @@ class JsonPMDA(PMDA): self.pmda_name = pmda_name PMDA.__init__(self, self.pmda_name, domain) self.connect_pmcd() - self.indom_idx = 0 + self.__cluster_indom = None self.numfetch = 0 self.metadata_name = 'metadata.json' - # cluster 0 is reserved for the static metrics - self.cluster_idx = 1 + # cache_idx 0 is reserved for the cluster cache. cluster 0 is + # reserved for the static metrics, so clusters that get added + # to the cache start with 1. + self.__cluster_cache = IndomCache(0, MAX_CLUSTER, self) - self.__metrics = {} # FIXME: python doesn't have a __pmParseDebug() wrapper. So, # if PCP_PYTHON_DEBUG has any value, turn debugging on. self.debug = ('PCP_PYTHON_DEBUG' in os.environ) + + # Try loading old cluster cache values. + self.__cluster_cache.load() + if self.__cluster_cache.len() == 0: + # If there weren't any old cluster cache values, we've got + # a bit of a problem. The indom cache only allocates + # consecutive values starting at 0. We want to start at 1, + # since cluster 0 is reserved for the static metrics. So, + # let's add a fake entry. + self.__cluster_cache.add_value('__internal__', 0) + + self.__metrics = {} self.__add_static_metrics() # Set up defaults for config variables. @@ -767,22 +941,24 @@ class JsonPMDA(PMDA): Create all the static metrics (not from a JSON source). ''' # Create our 'nsources' metric. - metric_info = Metric(self.pmda_name, 0, 0, self) + metric_info = Metric(self.pmda_name, 0, self) metric_info.name = 'nsources' metric_info.type = c_api.PM_TYPE_64 metric_info.sem = c_api.PM_SEM_COUNTER metric_info.desc = 'Number of JSON sources' + metric_info.idx = 0 metric_info.create() self.add_metric(metric_info.full_name, metric_info.obj, metric_info.desc) self.__metrics[metric_info.idx] = metric_info # Create our 'debug' metric. - metric_info = Metric(self.pmda_name, 0, 1, self) + metric_info = Metric(self.pmda_name, 0, self) metric_info.name = 'debug' metric_info.type = c_api.PM_TYPE_64 metric_info.sem = c_api.PM_SEM_INSTANT metric_info.desc = 'Debug logging state' + metric_info.idx = 1 metric_info.create() self.add_metric(metric_info.full_name, metric_info.obj, metric_info.desc) @@ -828,6 +1004,7 @@ class JsonPMDA(PMDA): dir_list = self.__trusted_directory_list else: dir_list = self.__directory_list + new_source_seen = False for directory in dir_list: for root, dummy, files in os.walk(directory): # Make sure we have the metadata file. @@ -845,16 +1022,39 @@ class JsonPMDA(PMDA): "file")): continue - # Add the new source. - if self.cluster_idx > MAX_CLUSTER: - self.log("Skipping source '%s' -" - " max cluster reached" % root) - continue - source = JsonSource(root, self.cluster_idx, - self, trusted) + # Create the new JsonSource. After the + # JsonSource has been initialized, it has + # parsed the metadata enough to optionally + # change the name. + source = JsonSource(root, self, trusted) + + # Try looking up the source name in the + # cluster cache. + try: + cluster_idx \ + = self.__cluster_cache.lookup_name(source.name) + if self.debug: + self.log("Found %s in cluster cache: %d" % + (source.name, cluster_idx)) + except KeyError: + try: + cluster_idx = self.__cluster_cache.next_value() + if self.debug: + self.log("allocating new cluster idx" + " %d for source %s" % + (cluster_idx, source.name)) + except ValueError: + self.log("Skipping source '%s' -" + " max cluster reached" % root) + continue + + if self.debug: + self.log("Adding source '%s', cluster_idx %d" + % (source.name, cluster_idx)) + self.__cluster_cache.add_value(source.name, cluster_idx) + source.cluster = cluster_idx self.sources_by_root[root] = source - self.sources_by_cluster[self.cluster_idx] = source - self.cluster_idx += 1 + self.sources_by_cluster[cluster_idx] = source # Notice we're going ahead and loading the # JSON data for new sources. If we're @@ -862,7 +1062,10 @@ class JsonPMDA(PMDA): # new data source, but we need the metadata # (for metrics) and data (for indoms). self.sources_by_root[root].load() + new_source_seen = True sources_seen[root] = 1 + if new_source_seen: + self.__cluster_cache.refresh() def __load_all_json(self): ''' @@ -957,4 +1160,5 @@ if __name__ == '__main__': #os.environ["PCP_PYTHON_DEBUG"] = "ALL" #os.environ["PCP_PYTHON_DEBUG"] = "APPL0|LIBPMDA" + #os.environ["PCP_PYTHON_DEBUG"] = "INDOM" JsonPMDA('json', 137).run() diff --git a/src/python/pcp/pmda.py b/src/python/pcp/pmda.py index 49203e0..26835f0 100644 --- a/src/python/pcp/pmda.py +++ b/src/python/pcp/pmda.py @@ -25,7 +25,7 @@ import os import cpmapi import cpmda from pcp.pmapi import pmContext as PCP -from pcp.pmapi import pmInDom, pmDesc, pmUnits +from pcp.pmapi import pmInDom, pmDesc, pmUnits, pmErr from ctypes.util import find_library from ctypes import CDLL, c_int, c_long, c_char_p, c_void_p, cast, byref @@ -55,6 +55,8 @@ LIBPCP_PMDA.pmdaCacheLookupKey.argtypes = [ POINTER(c_int), POINTER(c_void_p)] LIBPCP_PMDA.pmdaCacheOp.restype = c_int LIBPCP_PMDA.pmdaCacheOp.argtypes = [pmInDom, c_long] +LIBPCP_PMDA.pmdaCacheResize.restype = c_int +LIBPCP_PMDA.pmdaCacheResize.argtypes = [pmInDom, c_int] ## @@ -104,6 +106,39 @@ class pmdaIndom(Structure): self.it_indom = indom self.set_instances(indom, insts) + def __iter__(self): + # Generates an iterator for the cache. + if self.it_numinst < 0: + LIBPCP_PMDA.pmdaCacheOp(self.it_indom, + cpmda.PMDA_CACHE_WALK_REWIND) + while 1: + inst = LIBPCP_PMDA.pmdaCacheOp(self.it_indom, + cpmda.PMDA_CACHE_WALK_NEXT) + if inst < 0: + break + name = self.inst_name_lookup(inst) + if name: + yield (inst, name) + else: + for i in range(self.it_numinst): + inst = self.it_set[i].i_inst + name = self.inst_name_lookup(inst) + if name: + yield (inst, name) + + def inst_name_lookup(self, instance): + if self.it_numinst < 0: + name = (c_char_p)() + sts = LIBPCP_PMDA.pmdaCacheLookup(self.it_indom, instance, + byref(name), None) + if (sts == cpmda.PMDA_CACHE_ACTIVE): + return str(name.value.decode()) + elif self.it_numinst > 0: + for inst in self.it_set: + if (inst.i_inst == instance): + return str(inst.i_name.decode()) + return None + def set_list_instances(self, insts): instance_count = len(insts) if (instance_count == 0): @@ -113,6 +148,7 @@ class pmdaIndom(Structure): instance_array[i].i_inst = insts[i].i_inst instance_array[i].i_name = insts[i].i_name self.it_set = instance_array + self.it_numinst = instance_count def set_dict_instances(self, indom, insts): LIBPCP_PMDA.pmdaCacheOp(indom, cpmda.PMDA_CACHE_INACTIVE) @@ -134,6 +170,34 @@ class pmdaIndom(Structure): def __str__(self): return "pmdaIndom@%#lx indom=%#lx num=%d" % (addressof(self), self.it_indom, self.it_numinst) + def load(self): + if self.it_numinst <= 0: + sts = LIBPCP_PMDA.pmdaCacheOp(self.it_indom, cpmda.PMDA_CACHE_LOAD) + if sts < 0: + raise pmErr(sts) + else: + raise pmErr(cpmapi.PM_ERR_NYI) + + def cache_active(self): + if self.it_numinst <= 0: + LIBPCP_PMDA.pmdaCacheOp(self.it_indom, cpmda.PMDA_CACHE_ACTIVE) + else: + raise pmErr(cpmapi.PM_ERR_NYI) + + def cache_inactive(self): + if self.it_numinst <= 0: + LIBPCP_PMDA.pmdaCacheOp(self.it_indom, cpmda.PMDA_CACHE_INACTIVE) + else: + raise pmErr(cpmapi.PM_ERR_NYI) + + def cache_resize(self, maximum): + if self.it_numinst <= 0: + sts = LIBPCP_PMDA.pmdaCacheResize(self.it_indom, maximum) + if sts < 0: + raise pmErr(sts) + else: + raise pmErr(cpmapi.PM_ERR_NYI) + class pmdaUnits(pmUnits): """ Wrapper class for PMDAs defining their metrics (avoids pmapi import) """ def __init__(self, dimS, dimT, dimC, scaleS, scaleT, scaleC): @@ -240,13 +304,21 @@ class MetricDispatch(object): self._indom_helptext[indomid] = text def replace_indom(self, indom, insts): - replacement = pmdaIndom(indom, insts) + # Note that this function can take a numeric indom or a + # pmdaIndom. + if isinstance(indom, pmdaIndom): + it_indom = indom.it_indom + replacement = indom + else: + it_indom = indom + replacement = pmdaIndom(it_indom, insts) # list indoms need to keep the table up-to-date for libpcp_pmda if (isinstance(insts, list)): for entry in self._indomtable: - if (entry.it_indom == indom): + if (entry.it_indom == it_indom): entry = replacement - self._indoms[indom] = replacement + break + self._indoms[it_indom] = replacement def inst_lookup(self, indom, instance): """ @@ -268,17 +340,7 @@ class MetricDispatch(object): a specific instance domain. """ entry = self._indoms[indom] - if (entry.it_numinst < 0): - name = (c_char_p)() - sts = LIBPCP_PMDA.pmdaCacheLookup(indom, instance, byref(name), None) - if (sts == cpmda.PMDA_CACHE_ACTIVE): - return str(name.value.decode()) - elif (entry.it_numinst > 0 and entry.it_indom == indom): - for inst in entry.it_set: - if (inst.i_inst == instance): - return str(inst.i_name.decode()) - return None - + return entry.inst_name_lookup(instance) class PMDA(MetricDispatch): """ Defines a PCP performance metrics domain agent --------------080704020705060003010500-- From kenj@internode.on.net Thu May 7 16:18:03 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id B20BE7F37 for ; Thu, 7 May 2015 16:18:03 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 96C3B304053 for ; Thu, 7 May 2015 14:18:00 -0700 (PDT) X-ASG-Debug-ID: 1431033477-04bdf063205f6780001-S8gJnT Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id ORTubJf0sVdVue47 for ; Thu, 07 May 2015 14:17:58 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.131 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CVAQAi1ktV/6Eh0XYNT4NiXoMexDGIEgEBAQEBAYVVgQsCBSECEQJMDQgBAYg1smtwk1EMHASBIZINgUUFlkqdC4QrXQGCRQEBAQ Received: from ppp118-209-33-161.lns20.mel4.internode.on.net (HELO [192.168.1.100]) ([118.209.33.161]) by ipmail07.adl2.internode.on.net with ESMTP; 08 May 2015 06:47:57 +0930 Message-ID: <554BD678.70207@internode.on.net> Date: Fri, 08 May 2015 07:17:44 +1000 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: PCP Subject: build failure on fc20 Content-Type: text/plain; charset=utf-8 X-ASG-Orig-Subj: build failure on fc20 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1431033478 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18707 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- My build just started failing on fc20 thusly ... + /usr/bin/gawk --posix ' ... printf ("%%attr(%s,%s,%s) %s\n", $2, $3, $4, $6) >> f } $1 == "l" { print "%attr(0777,root,root)", $3 >> f }' gawk: cmd. line:133: else if (import_sheet2pcp[$NF]) f="import_sheet2pcp_files.rpm"; gawk: cmd. line:133: ^ yacc stack overflow Anyone else seeing this? Better still, any suggestions? This https://bugzilla.redhat.com/show_bug.cgi?id=743343 suggests the problem may have been there for ages, we're just hitting it now because we have lots more packages ... 8^) Can we change this code from if () ... else if () ... ... to if () ... if () ... ... From kenj@internode.on.net Thu May 7 17:24:06 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 3C1207F37 for ; Thu, 7 May 2015 17:24:06 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 2E3E28F8078 for ; Thu, 7 May 2015 15:24:06 -0700 (PDT) X-ASG-Debug-ID: 1431037440-04cbb056b25e8e40001-S8gJnT Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id p9FsiIixIRQ97v7A for ; Thu, 07 May 2015 15:24:00 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.131 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CVAQBa5UtV/6Eh0XYNT4dezEABAQEBAQGFVRVANgIFFgsCCwMCAQIBSw0IAQG7HnCTfoEhkg2BRQWzVYQrgyMBAQE Received: from ppp118-209-33-161.lns20.mel4.internode.on.net (HELO [192.168.1.100]) ([118.209.33.161]) by ipmail07.adl2.internode.on.net with ESMTP; 08 May 2015 07:53:59 +0930 Message-ID: <554BE5F3.5080204@internode.on.net> Date: Fri, 08 May 2015 08:23:47 +1000 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: PCP Subject: install failing on openSUSE 13.1 Content-Type: text/plain; charset=utf-8; format=flowed X-ASG-Orig-Subj: install failing on openSUSE 13.1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1431037440 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18710 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- My vm14, installing failing after recent rpm restructuring ... error: Failed dependencies: pcp-pmda-rpm is needed by pcp-collector-3.10.5-4.i586 pcp-pmda-rpm is needed by pcp-compat-3.10.5-4.i586 pcp-gui is needed by pcp-monitor-3.10.5-4.i586 postfix-perl-scripts is needed by pcp-pmda-postfix-3.10.5-4.i586 The postfix one is OK (I have a qa/admin/check-vm change pending to check for this new dependency). The others look like new packaging problems. pcp-pmda-rpm is not built on this platform, ditto for pcp-gui, so I think the dependency clauses need to include some conditional code ... if we're not making pcp-foo then the same logic should guard the inclusion of a pcp-foo dependency in the other packages. I've left this system alone ... let me know what additional information might help traige this. From nscott@redhat.com Thu May 7 17:30:30 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 4D2847F37 for ; Thu, 7 May 2015 17:30:30 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 3B0D18F8078 for ; Thu, 7 May 2015 15:30:30 -0700 (PDT) X-ASG-Debug-ID: 1431037828-04cb6c1cc958b130001-S8gJnT Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) by cuda.sgi.com with ESMTP id kNLLinpIhq6V85q2 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 15:30:28 -0700 (PDT) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.37 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t47MUPZB065004; Thu, 7 May 2015 18:30:25 -0400 Date: Thu, 7 May 2015 18:30:25 -0400 (EDT) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: PCP Message-ID: <1299196352.15305499.1431037825092.JavaMail.zimbra@redhat.com> In-Reply-To: <554BD678.70207@internode.on.net> References: <554BD678.70207@internode.on.net> Subject: Re: [pcp] build failure on fc20 MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] build failure on fc20 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.64.50.253] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF37 (Linux)/8.0.6_GA_5922) Thread-Topic: build failure on fc20 Thread-Index: O6xP63HpFY+TzCD1y7lmQopML/s7aQ== X-Barracuda-Connect: mx5-phx2.redhat.com[209.132.183.37] X-Barracuda-Start-Time: 1431037828 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18710 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > My build just started failing on fc20 thusly ... > > + /usr/bin/gawk --posix ' > ... > printf ("%%attr(%s,%s,%s) %s\n", $2, $3, $4, $6) >> f } > $1 == "l" { print "%attr(0777,root,root)", $3 >> f }' > gawk: cmd. line:133: else if (import_sheet2pcp[$NF]) > f="import_sheet2pcp_files.rpm"; > gawk: cmd. line:133: ^ yacc stack > overflow > > Anyone else seeing this? I've got a regular fedora 20 build here & not seeing this FWLIW. > Better still, any suggestions? > > This https://bugzilla.redhat.com/show_bug.cgi?id=743343 suggests the problem > may have been there for ages, we're just hitting it now because we have lots > more packages ... 8^) > > Can we change this code from > if () ... > else if () ... > ... > > to > if () ... > if () ... > ... >From a quick reading of the code, I think that'd be safe & correct, yes. cheers. -- Nathan From kenj@internode.on.net Thu May 7 17:33:48 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id A11137F37 for ; Thu, 7 May 2015 17:33:48 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 74B6B304059 for ; Thu, 7 May 2015 15:33:45 -0700 (PDT) X-ASG-Debug-ID: 1431038019-04bdf063235f9000001-S8gJnT Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id uCzSBQb1zDFCcHW2 for ; Thu, 07 May 2015 15:33:40 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.131 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CWAQC350tV/6Eh0XYNT4NiXsdPhgUCgggBAQEBAQGFLAEBBDhAEQsYCRYPCQMCAQIBRRMIAQGINbJtlEQBAQEHAQEBAR6LOoUMFoQXBZZKh2iNYIdDggmCIl0BgkUBAQE Received: from ppp118-209-33-161.lns20.mel4.internode.on.net (HELO [192.168.1.100]) ([118.209.33.161]) by ipmail07.adl2.internode.on.net with ESMTP; 08 May 2015 08:03:39 +0930 Message-ID: <554BE836.9060302@internode.on.net> Date: Fri, 08 May 2015 08:33:26 +1000 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: Re: [pcp] build failure on fc20 [fixed] References: <554BD678.70207@internode.on.net> X-ASG-Orig-Subj: Re: [pcp] build failure on fc20 [fixed] In-Reply-To: <554BD678.70207@internode.on.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1431038019 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18710 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 08/05/15 07:17, Ken McDonell wrote: > My build just started failing on fc20 thusly ... > > + /usr/bin/gawk --posix ' > ... > printf ("%%attr(%s,%s,%s) %s\n", $2, $3, $4, $6) >> f } > $1 == "l" { print "%attr(0777,root,root)", $3 >> f }' > gawk: cmd. line:133: else if (import_sheet2pcp[$NF]) f="import_sheet2pcp_files.rpm"; > gawk: cmd. line:133: ^ yacc stack overflow > > Anyone else seeing this? > > Better still, any suggestions? > > This https://bugzilla.redhat.com/show_bug.cgi?id=743343 suggests the problem may have been there for ages, we're just hitting it now because we have lots more packages ... 8^) > > Can we change this code from > if () ... > else if () ... > ... > > to > if () ... > if () ... > ... Doing a yum update fixed this ... so probably a gawk build problem that was fixed at some point in the fc20 update cycle. Looks like unravelling the nested if-else-else ... in pcp.spec.in would work in case this problem reappears elsewhere. From kenj@internode.on.net Thu May 7 17:46:02 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 4F8417F37 for ; Thu, 7 May 2015 17:46:02 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id D0874AC002 for ; Thu, 7 May 2015 15:45:58 -0700 (PDT) X-ASG-Debug-ID: 1431038756-04cbb056b45e9590001-S8gJnT Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id C3FDnRwppYFJPZub for ; Thu, 07 May 2015 15:45:56 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.131 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CWAQDU6UtV/6Eh0XYNT882gl4CgggBAQEBAQGFLAEBBDhAARALGAkWDwkDAgECAUUGDQEHAQEVuxWURAEBAQEBAQQBAQEBAQEBG4s6hQUHhC0BBIZZrHyEK4MjAQEB Received: from ppp118-209-33-161.lns20.mel4.internode.on.net (HELO [192.168.1.100]) ([118.209.33.161]) by ipmail07.adl2.internode.on.net with ESMTP; 08 May 2015 08:15:55 +0930 Message-ID: <554BEB16.7030208@internode.on.net> Date: Fri, 08 May 2015 08:45:42 +1000 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: pcp@oss.sgi.com Subject: Re: Calculated/derived metrics? References: <5534C680.2020709@redhat.com> <493537984.3276058.1429528962326.JavaMail.zimbra@redhat.com> <5534EBA8.4030509@redhat.com> <1644393599.3651017.1429563442835.JavaMail.zimbra@redhat.com> <55364606.1000503@redhat.com> <55472B40.7050800@redhat.com> <5547DE11.5050800@internode.on.net> <5549E4CD.5000408@redhat.com> <554AFE4E.80000@internode.on.net> X-ASG-Orig-Subj: Re: Calculated/derived metrics? In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1431038756 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18710 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header On 08/05/15 06:35, Frank Ch. Eigler wrote: > ... > Is the rate() derived-metrics function applicable here? If I understand Marko's requirement he'd like to get something close to the I/O rate of the process over its life, rather than over the last time period (hotproc.io.write_bytes by itself will give you the latter, as will rate(hotproc.io.write_bytes) in a derived metric). I think the scenario is like this ... ---+-------------------------------+------ >time | | start_time uptime 0 100 170 200 >write_bytes and Marko wants 200/(uptime-start_time) at time "uptime" From lberk@redhat.com Thu May 7 17:52:03 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 3FB6C7F37 for ; Thu, 7 May 2015 17:52:03 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 1D2568F8037 for ; Thu, 7 May 2015 15:52:02 -0700 (PDT) X-ASG-Debug-ID: 1431039121-04cbb056b15e9760001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id DV2jCloZ9m8nu9Jx (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 15:52:02 -0700 (PDT) X-Barracuda-Envelope-From: lberk@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t47Mplc5006156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 7 May 2015 18:51:47 -0400 Received: from toium (vpn-61-112.rdu2.redhat.com [10.10.61.112]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t47MpkNe020792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 May 2015 18:51:46 -0400 From: Lukas Berk To: Ken McDonell Cc: PCP Subject: Re: [pcp] install failing on openSUSE 13.1 References: <554BE5F3.5080204@internode.on.net> X-ASG-Orig-Subj: Re: [pcp] install failing on openSUSE 13.1 Date: Thu, 07 May 2015 18:51:45 -0400 In-Reply-To: <554BE5F3.5080204@internode.on.net> (Ken McDonell's message of "Fri, 08 May 2015 08:23:47 +1000") Message-ID: <87egmsknlq.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1431039121 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hey Ken, Ken McDonell writes: > error: Failed dependencies: > pcp-pmda-rpm is needed by pcp-collector-3.10.5-4.i586 > pcp-pmda-rpm is needed by pcp-compat-3.10.5-4.i586 > pcp-gui is needed by pcp-monitor-3.10.5-4.i586 > postfix-perl-scripts is needed by pcp-pmda-postfix-3.10.5-4.i586 > > The postfix one is OK (I have a qa/admin/check-vm change pending to > check for this new dependency). > > The others look like new packaging problems. pcp-pmda-rpm is not > built on this platform, ditto for pcp-gui, so I think the dependency > clauses need to include some conditional code ... if we're not making > pcp-foo then the same logic should guard the inclusion of a pcp-foo > dependency in the other packages. > > I've left this system alone ... let me know what additional > information might help traige this. Thanks for catching this, I've commited what I believe is the proper fix to my lberk/dev branch. I'll send out a pcp-updates mail shortly with a few other patches. Cheers, Lukas From lberk@redhat.com Thu May 7 17:56:15 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id E7A4C7F37 for ; Thu, 7 May 2015 17:56:15 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id D7C3630404E for ; Thu, 7 May 2015 15:56:15 -0700 (PDT) X-ASG-Debug-ID: 1431039374-04cb6c1cc858baf0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id MkXzsxVgLPiG89wH (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 15:56:14 -0700 (PDT) X-Barracuda-Envelope-From: lberk@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t47MuEia023863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 7 May 2015 18:56:14 -0400 Received: from toium (vpn-61-112.rdu2.redhat.com [10.10.61.112]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t47MuDrM024803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 7 May 2015 18:56:13 -0400 From: Lukas Berk To: pcp@oss.sgi.com Subject: pcp-updates spin-rawhide, docs, pcp.spec.in fixes Date: Thu, 07 May 2015 18:56:12 -0400 X-ASG-Orig-Subj: pcp-updates spin-rawhide, docs, pcp.spec.in fixes Message-ID: <878ud0kneb.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1431039374 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi, Please see lberk/dev on git://sourceware.org/git/pcpfans.git for various fixups. Correcting a doc url, robustifying spin-rawhide, and the opensuse build issue Ken was seeing. Cheers, Lukas build/rpm/pcp.spec.in | 17 ++++++++++++++--- man/html/guide.html | 2 +- scripts/spin-rawhide | 12 ++++++++---- 3 files changed, 23 insertions(+), 8 deletions(-) commit 3b8a24dbdcf0835cdb72edcfcb8987e65f4d9d11 Author: Lukas Berk Date: Thu May 7 18:49:33 2015 -0400 Wrap pcp-pmda-rpm and pcp-gui with proper %if checks pcp-pmda-rpm and pcp-gui aren't built on some platforms, wrapping them with proper checks so it doesn't fail on other platforms commit 7e35f96431dcb6e913d017c1811b844e6d1268ef Author: Lukas Berk Date: Thu May 7 13:35:19 2015 -0400 Fix location of pcp-webjs gitweb in the pcp guide commit ff6b1024f3dfcd03512fb55b1390582e0b58c9ee Author: Lukas Berk Date: Thu May 7 11:19:56 2015 -0400 spin-rawhide: Extract version info from VERSION.pcp At times (specifically after a release), the spec file can become out of sync with the VERSION.pcp. This tweak of spin-rawhide gets the specific version info from the definitive source (VERSION.pcp). From nscott@redhat.com Thu May 7 18:35:16 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 70F9D7F37 for ; Thu, 7 May 2015 18:35:16 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id EF5B2AC002 for ; Thu, 7 May 2015 16:35:12 -0700 (PDT) X-ASG-Debug-ID: 1431041710-04cb6c1cc858d100001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id m7rv5NjxjMx4rMfh (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 16:35:11 -0700 (PDT) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t47NZAZh007162; Thu, 7 May 2015 19:35:10 -0400 Date: Thu, 7 May 2015 19:35:10 -0400 (EDT) From: Nathan Scott Reply-To: Nathan Scott To: David Smith Cc: pcp Message-ID: <2131769747.15314020.1431041710334.JavaMail.zimbra@redhat.com> In-Reply-To: <554BD38B.4060300@redhat.com> References: <54F9F92D.4010202@redhat.com> <552D6524.1030803@redhat.com> <1237712965.18667183.1429054767135.JavaMail.zimbra@redhat.com> <5536C228.8010001@redhat.com> <1344441557.4430503.1429658863072.JavaMail.zimbra@redhat.com> <55493338.3050609@redhat.com> <422876605.13652980.1430893026406.JavaMail.zimbra@redhat.com> <554BD38B.4060300@redhat.com> Subject: Re: [pcp] JSON PMDA MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] JSON PMDA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.64.50.253] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF37 (Linux)/8.0.6_GA_5922) Thread-Topic: JSON PMDA Thread-Index: 6Hu36q+kcJnQWFTSNSBc/dNYqBnDmw== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1431041711 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18712 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > >> [...] > > This patch is cleaned up a good bit. I fixed the above items and made > several changes to pmda.py. > > I've got a question about the "exports" file, which I've never messed > with before. Should I have put the new function at the end of the list? > Do I need to define a new library version? Yep - a PCP_PMDA_3.5 will be needed. > I've got a "philosophy" question about the pmda itself. Originally, each > array had its own indom cache. For this new version, I've switched to > one indom cache per JSON source (each JSON source is also in its own > cluster). I think I can see a way to switch back to the original method > (by adding another cache that maps cache numbers back to arrays), but I > wasn't sure which way was more "correct". >From a PCP philosophy point of view an indom represents a set-of-somethings from one PMDA (e.g. set of disks, set of CPUs) - so, in this case, if more than one JSON-defined metric has values expanded across a set-of-somethings those metrics should use the *same* indom (i.e. same serial#). Provided that can be represented, I guess it doesn't matter how things are managed internally in the PMDA. cheers. -- Nathan From mgoodwin@redhat.com Thu May 7 19:55:53 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id E498B7F37 for ; Thu, 7 May 2015 19:55:52 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 8234AAC002 for ; Thu, 7 May 2015 17:55:49 -0700 (PDT) X-ASG-Debug-ID: 1431046545-04bdf063235fd8a0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Bt9JG1mFpg0OEH3v (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 17:55:45 -0700 (PDT) X-Barracuda-Envelope-From: mgoodwin@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t480tUk1015819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 7 May 2015 20:55:30 -0400 Received: from [10.64.51.72] (vpn1-51-72.bne.redhat.com [10.64.51.72]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t480tSM8002672; Thu, 7 May 2015 20:55:29 -0400 Message-ID: <554C097F.4020406@redhat.com> Date: Fri, 08 May 2015 10:55:27 +1000 From: Mark Goodwin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ken McDonell CC: pcp@oss.sgi.com Subject: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes References: <878ud0kneb.fsf@redhat.com> X-ASG-Orig-Subj: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes In-Reply-To: <878ud0kneb.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1431046545 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Ken, if you have a minute could you pull this fix from Lukas and check it builds and installs OK on that OpenSuSE13.2 vm of yours? (or give me access?) f21 builds and installs fine with or without the rpm-devel package installed, i.e. with or without pcp-pmda-rpm being built or not, so I guess the OpenSuSE rpm spec parser is less tolerant or something. thanks -- Mark On 05/08/2015 08:56 AM, Lukas Berk wrote: > Hi, > > Please see lberk/dev on git://sourceware.org/git/pcpfans.git > for various fixups. Correcting a doc url, robustifying spin-rawhide, > and the opensuse build issue Ken was seeing. > > Cheers, > > Lukas > > build/rpm/pcp.spec.in | 17 ++++++++++++++--- > man/html/guide.html | 2 +- > scripts/spin-rawhide | 12 ++++++++---- > 3 files changed, 23 insertions(+), 8 deletions(-) > > commit 3b8a24dbdcf0835cdb72edcfcb8987e65f4d9d11 > Author: Lukas Berk > Date: Thu May 7 18:49:33 2015 -0400 > > Wrap pcp-pmda-rpm and pcp-gui with proper %if checks > > pcp-pmda-rpm and pcp-gui aren't built on some platforms, > wrapping them with proper checks so it doesn't fail on other platforms > > commit 7e35f96431dcb6e913d017c1811b844e6d1268ef > Author: Lukas Berk > Date: Thu May 7 13:35:19 2015 -0400 > > Fix location of pcp-webjs gitweb in the pcp guide > > commit ff6b1024f3dfcd03512fb55b1390582e0b58c9ee > Author: Lukas Berk > Date: Thu May 7 11:19:56 2015 -0400 > > spin-rawhide: Extract version info from VERSION.pcp > > At times (specifically after a release), the spec file can become out > of sync with the VERSION.pcp. This tweak of spin-rawhide gets the > specific version info from the definitive source (VERSION.pcp). > > _______________________________________________ > pcp mailing list > pcp@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/pcp > From kenj@internode.on.net Thu May 7 20:06:51 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id E19577F37 for ; Thu, 7 May 2015 20:06:51 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 7EAEDAC003 for ; Thu, 7 May 2015 18:06:48 -0700 (PDT) X-ASG-Debug-ID: 1431047201-04cbb056b15edd00001-S8gJnT Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id uStVw59YLKx54p1h for ; Thu, 07 May 2015 18:06:42 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.131 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CWAQDJCkxV/6Eh0XYNT4NiXsdGhg0CggwBAQEBAQGFKwEBAQMBeQULCw4KCSUPAkYGDQEHAQGIILJ3lEYBAQEBAQEEAQEBAQEBARuLOoQzAQFQB4QtAQSWSogllGaEK12BDIE6AQEB Received: from ppp118-209-33-161.lns20.mel4.internode.on.net (HELO [192.168.1.100]) ([118.209.33.161]) by ipmail07.adl2.internode.on.net with ESMTP; 08 May 2015 10:36:41 +0930 Message-ID: <554C0C14.60900@internode.on.net> Date: Fri, 08 May 2015 11:06:28 +1000 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Lukas Berk CC: PCP Subject: Re: [pcp] install failing on openSUSE 13.1 References: <554BE5F3.5080204@internode.on.net> <87egmsknlq.fsf@redhat.com> X-ASG-Orig-Subj: Re: [pcp] install failing on openSUSE 13.1 In-Reply-To: <87egmsknlq.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1431047201 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18713 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 08/05/15 08:51, Lukas Berk wrote: >> ... >> postfix-perl-scripts is needed by pcp-pmda-postfix-3.10.5-4.i586 > Thanks for catching this, I've commited what I believe is the proper fix > to my lberk/dev branch. I'll send out a pcp-updates mail shortly with a > few other patches. Lukas, I've cherry-picked these, thanks. And they resolve the compat dependency ones. But the postfix PMDA is a real problem! 1. in this version of opensuse there is no postfix-perl-scripts rpm 2. there is (non-executable!) qshape.pl hidden in an obscure place in the postfix-docs rpm (!!) 3. there is already a guard in the pmda's Install script checking for an executable qshape I think we should drop the (newly added?) Requires: clause here so builds will work everywhere and perhaps add some extra verbage from the pmda's Install script to provide advice on where to find qshape for the various platforms, e.g. this would seem to be the advice for opensuse13.1 (a) install postfix-docs (b) sudo chmod 755 /usr/share/doc/packages/postfix-doc/auxiliary/qshape/qshape.pl (c) sudo ln -s /usr/share/doc/packages/postfix-doc/auxiliary/qshape/qshape.pl /usr/bin/qshape From nscott@redhat.com Thu May 7 20:16:39 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 0ABFA7F37 for ; Thu, 7 May 2015 20:16:39 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 988A0AC003 for ; Thu, 7 May 2015 18:16:38 -0700 (PDT) X-ASG-Debug-ID: 1431047796-04bdf063225fe670001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id SY8HyXNerKkZcZQZ (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 18:16:37 -0700 (PDT) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t481GYuc021182; Thu, 7 May 2015 21:16:34 -0400 Date: Thu, 7 May 2015 21:16:34 -0400 (EDT) From: Nathan Scott Reply-To: Nathan Scott To: Lukas Berk , Ken McDonell Cc: PCP Message-ID: <197355498.15408258.1431047794187.JavaMail.zimbra@redhat.com> In-Reply-To: <554C0C14.60900@internode.on.net> References: <554BE5F3.5080204@internode.on.net> <87egmsknlq.fsf@redhat.com> <554C0C14.60900@internode.on.net> Subject: Re: [pcp] install failing on openSUSE 13.1 MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] install failing on openSUSE 13.1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.64.50.253] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF37 (Linux)/8.0.6_GA_5922) Thread-Topic: install failing on openSUSE 13.1 Thread-Index: MbujvrHJm9vteQMA+7kIdkK2tQwpFw== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1431047796 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18713 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > On 08/05/15 08:51, Lukas Berk wrote: > >> ... > >> postfix-perl-scripts is needed by pcp-pmda-postfix-3.10.5-4.i586 > > > Thanks for catching this, I've commited what I believe is the proper fix > > to my lberk/dev branch. I'll send out a pcp-updates mail shortly with a > > few other patches. > > Lukas, > > I've cherry-picked these, thanks. And they resolve the compat dependency > ones. > > But the postfix PMDA is a real problem! > > 1. in this version of opensuse there is no postfix-perl-scripts rpm > 2. there is (non-executable!) qshape.pl hidden in an obscure place in the > postfix-docs rpm (!!) > 3. there is already a guard in the pmda's Install script checking for an > executable qshape > > I think we should drop the (newly added?) Requires: clause here so builds > will work everywhere and perhaps add some extra verbage from the pmda's > Install script to provide advice on where to find qshape for the various > platforms, e.g. this would seem to be the advice for opensuse13.1 Maybe use: %if "%{_vendor}" == "redhat" around the dependency, since we really want it kept for Fedora & RHEL. > (a) install postfix-docs (and maybe a vendor == "suse" for that dependency)? > (b) sudo chmod 755 > /usr/share/doc/packages/postfix-doc/auxiliary/qshape/qshape.pl > (c) sudo ln -s /usr/share/doc/packages/postfix-doc/auxiliary/qshape/qshape.pl > /usr/bin/qshape > That's not going to be end-user-friendly (ideally, it'd work out-of-the-box). We could avoid those steps via Install finding an appropriate location and passing it to the PMDA via configuration file, then running it with "perl $PCP_POSTFIX_QSHAPE" and passing (to avoid the chmod). cheers. -- Nathan From kenj@internode.on.net Thu May 7 21:28:07 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 22C9D7F37 for ; Thu, 7 May 2015 21:28:07 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 101918F8070 for ; Thu, 7 May 2015 19:28:07 -0700 (PDT) X-ASG-Debug-ID: 1431052080-04cb6c1cc7591610001-S8gJnT Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id e4r74CErH7YFmDCS for ; Thu, 07 May 2015 19:28:01 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.131 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CWAQDdHUxV/6Eh0XYNT880glgEAgKCDgEBAQEBAYUsAQEEOEARCxgJFg8JAwIBAgFFBwwIAQG7DJRPAQEBBwEBAQEeizqFDIQtAQSeMoNYjXiDU4IJIhyBZIMjAQEB Received: from ppp118-209-33-161.lns20.mel4.internode.on.net (HELO [192.168.1.100]) ([118.209.33.161]) by ipmail07.adl2.internode.on.net with ESMTP; 08 May 2015 11:58:00 +0930 Message-ID: <554C1F23.1090609@internode.on.net> Date: Fri, 08 May 2015 12:27:47 +1000 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: myllynen@redhat.com, pcp@oss.sgi.com Subject: Re: [pcp] Calculated/derived metrics? References: <5534C680.2020709@redhat.com> <493537984.3276058.1429528962326.JavaMail.zimbra@redhat.com> <5534EBA8.4030509@redhat.com> <1644393599.3651017.1429563442835.JavaMail.zimbra@redhat.com> <55364606.1000503@redhat.com> <55472B40.7050800@redhat.com> <5547DE11.5050800@internode.on.net> <5549E4CD.5000408@redhat.com> <554AFE4E.80000@internode.on.net> <554B3E8F.3080904@redhat.com> X-ASG-Orig-Subj: Re: [pcp] Calculated/derived metrics? In-Reply-To: <554B3E8F.3080904@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1431052080 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18715 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 07/05/15 20:29, Marko Myllynen wrote: > ... > once I understand this a bit better myself I'll send a patch to add a > note about derived metrics in the PCP Quick Guide. I did search for > "calculate" and "derive" from the books but didn't find anything about > derived metrics from there. That would be good. Derived metrics happened much later than the last updates to the books from SGI, so it is not surprising there is no mention there. > ... >> And I'm not sure why the /100 is required, could you please explain >> that part? > > kernel.all.uptime is in seconds but hotproc.psinfo.start_time is in > jiffies and although jiffies-to-seconds is not necessarily a trivial > operation [1], /100 seemed to provide "close enough" results during my > tests. ... Be careful. We (in PCPland) try very hard to avoid platform-variant and decade-variant units of measure ... blocks and hz and jiffies are all in this bag. So no matter what units the base instrumentation is in, the PMDA is responsible for translating it to something useful and invariant ... like seconds in this case. $ pminfo -d hotproc.psinfo.start_time kernel.all.uptime hotproc.psinfo.start_time Data Type: 32-bit unsigned int InDom: 3.39 0xc00027 Semantics: discrete Units: sec kernel.all.uptime Data Type: 32-bit unsigned int InDom: PM_INDOM_NULL 0xffffffff Semantics: instant Units: sec But unfortunately in this case the PMDA implementor says the metrics are seconds, but they are not (see the example below) ... this is a BUG .. the PMDA should return hotproc.psinfo.start_time either /100 and call it seconds or *10 and call it msec (and increase it to 64-bits in this case). # pminfo -f proc.psinfo.start_time | sed -e 's/.* value //' | sort -nr | head -2 ; pminfo -f kernel.all.uptime 9086825 9086825 kernel.all.uptime value 90868 If this was fixed you would not need the /100. > ... > Now, if we're in the business of adding more stuff to your RFE queue.. > ;-) Would you see it feasible to use derived metrics to derive metrics? > For example, in your example you had: > > mytest.divisor = hotproc.psinfo.start_time - kernel.all.uptime > mytest.marko = hotproc.psinfo.rss / (hotproc.psinfo.start_time - > kernel.all.uptime) > > It would be nice to be able to write this as: > > mytest.divisor = hotproc.psinfo.start_time - kernel.all.uptime > mytest.marko = hotproc.psinfo.rss / mytest.divisor I don't think nested definitions are going to happen ... the code behind this is already pretty complex ... but I could entertain a pmie-style macro definition and substitution that would achieve the same effect. From wwwrun@oss.sgi.com Thu May 7 22:59:09 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,NO_RELAYS autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: by oss.sgi.com (Postfix, from userid 30) id 8F0ED7F4E; Thu, 7 May 2015 22:59:09 -0500 (CDT) From: bugzilla-daemon@oss.sgi.com To: pcp@oss.sgi.com Subject: [Bug 918] pcpqa execution with less manual setup Date: Fri, 08 May 2015 03:59:09 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Classification: Unclassified X-Bugzilla-Product: pcp X-Bugzilla-Component: pcp X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: nathans@debian.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: kenj@internode.on.net X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: multipart/alternative; boundary="1431057549.fAA52.11313"; charset="us-ascii" X-Bugzilla-URL: http://oss.sgi.com/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 --1431057549.fAA52.11313 Date: Thu, 7 May 2015 22:59:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" http://oss.sgi.com/bugzilla/show_bug.cgi?id=918 Nathan Scott changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |nathans@debian.org Resolution|--- |FIXED --- Comment #1 from Nathan Scott --- This is resolved - mainly thanks to Milos, Ken & other folks work over time. The pcpqa user has long since been created as part of package installs, everything else needed (pmcd setup, primary logger, etc) is handled by "make setup && ./check -s -C -x verify". -- You are receiving this mail because: You are on the CC list for the bug. --1431057549.fAA52.11313 Date: Thu, 7 May 2015 22:59:09 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Nathan Scott changed bug 918

What	Removed	Added
Status	NEW	RESOLVED
CC		nathans@debian.org
Resolution	---	FIXED

Comment # 1 on bug 918 from Nathan Scott

This is resolved - mainly thanks to Milos, Ken & other folks work over time. 
The pcpqa user has long since been created as part of package installs,
everything else needed (pmcd setup, primary logger, etc) is handled by "make
setup && ./check -s -C -x verify".

You are receiving this mail because:

You are on the CC list for the bug.

--1431057549.fAA52.11313-- From pcp-announce-bounces@oss.sgi.com Fri May 8 01:26:36 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from oss.sgi.com (localhost [IPv6:::1]) by oss.sgi.com (Postfix) with ESMTP id 42CEF7F47; Fri, 8 May 2015 01:26:36 -0500 (CDT) X-Original-To: pcp-announce@oss.sgi.com Delivered-To: pcp-announce@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 5F7AB7F37 for ; Fri, 8 May 2015 01:26:34 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 520D58F8039 for ; Thu, 7 May 2015 23:26:31 -0700 (PDT) X-ASG-Debug-ID: 1431066384-04cbb056b45f3350001-87ZIJf Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) by cuda.sgi.com with ESMTP id Vhbl8vLQEYv1WuH1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 07 May 2015 23:26:25 -0700 (PDT) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.37 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t486QOgr011642 for ; Fri, 8 May 2015 02:26:24 -0400 Date: Fri, 8 May 2015 02:26:24 -0400 (EDT) From: Nathan Scott To: pcp-announce Message-ID: <1720576643.15449479.1431066384395.JavaMail.zimbra@redhat.com> In-Reply-To: <1866084063.15440140.1431062836766.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 X-ASG-Orig-Subj: Community PCP roadmap X-Originating-IP: [10.64.50.253] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF37 (Linux)/8.0.6_GA_5922) Thread-Topic: Community PCP roadmap Thread-Index: 6RkKgfZsAhk79c3BNuwQc8EZ00LLuw== X-Barracuda-Connect: mx5-phx2.redhat.com[209.132.183.37] X-Barracuda-Start-Time: 1431066385 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18719 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Subject: [pcp-announce] Community PCP roadmap X-BeenThere: pcp-announce@oss.sgi.com X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Nathan Scott List-Id: Performance Co-Pilot announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pcp-announce-bounces@oss.sgi.com Sender: pcp-announce-bounces@oss.sgi.com Hi all, Alot of people are excited about PCP and we keep getting asked now "what's next? what's the plan for PCP? how can I help?" It's a complex task tracking the work being done on PCP across the various groups within Red Hat, let alone everyone else in the community - but, let's give it a crack! Lukas has setup a public task board, accessible via: http://pcp.io/roadmap It contains an initial attempt at capturing all the current work, planned work for the next three PCP releases, then wishlist items beyond that. Could I ask anyone who is a regular contributor, or who plans to hack on PCP in the foreseeable future to visit the above URL and add your work in. If I know about your work, you'll likely find it there already, just waiting to be claimed - go right ahead! This is optional, not mandatory when sending new code, of course. Please only add things that you *really intend to work on*, too. It is not intended to replace any of the bug tracking systems, it's more of a interactive coordination and collaboration tool, and a way to improve visibility for people outside the developer community too. The way to read the board is from left to right. The cards there show our best attempt so far to represent current and planned work (bear in mind that plans can change at any time). If you create an account there and want to edit/add your work, send either Lukas or myself your username, we'll add you to the board & off you go. cheers. -- Nathan _______________________________________________ pcp-announce mailing list pcp-announce@oss.sgi.com http://oss.sgi.com/mailman/listinfo/pcp-announce From nscott@redhat.com Fri May 8 02:02:59 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id EFC447F3F for ; Fri, 8 May 2015 02:02:58 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id D75F78F8035 for ; Fri, 8 May 2015 00:02:55 -0700 (PDT) X-ASG-Debug-ID: 1431068570-04cbb056b45f3c30001-S8gJnT Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) by cuda.sgi.com with ESMTP id gcu2VXWx1MgdaQQ5 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 08 May 2015 00:02:50 -0700 (PDT) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.37 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4872mVA017627; Fri, 8 May 2015 03:02:48 -0400 Date: Fri, 8 May 2015 03:02:48 -0400 (EDT) From: Nathan Scott Reply-To: Nathan Scott To: Martins Innus Cc: pcp@oss.sgi.com Message-ID: <1373257836.15456190.1431068568719.JavaMail.zimbra@redhat.com> In-Reply-To: <554B7E8C.5040603@buffalo.edu> References: <554B7E8C.5040603@buffalo.edu> Subject: Re: [pcp] pmda timeout workarounds MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pmda timeout workarounds Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.64.50.253] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF37 (Linux)/8.0.6_GA_5922) Thread-Topic: pmda timeout workarounds Thread-Index: gXxm6tcgPOTDgUK4KF+LGz6l1T0Oxw== X-Barracuda-Connect: mx5-phx2.redhat.com[209.132.183.37] X-Barracuda-Start-Time: 1431068570 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18719 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Hi Martins, ----- Original Message ----- > [...] > > Barring any other suggestions, my plan would be to handle these issues > on a case by case basis depending on the semantics of the pmda data. > > For the slurm pmda, the data is tolerant to some reporting drift so I > would have a separate thread that updates a shared data structure > periodically, and any fetch just reports the most recent information. Sounds fine & similar sorts of approaches other PMDAs are taking. > For gpfs, we really care about getting the counters in a timely > fashion. So can I just return PM_ERR_AGAIN to a client request for a > pmda fetch if the request is taking too long, and the client will do > "the right thing"? Yes. > Where the right thing for a pmlogger instance is to > probably record no value for that timestep. It'll record the exact error code for that metric, within the pmResult, IIRC. > Proc probably would be a mix of these 2 solutions depending on the metric. > > Is that the right way forward, or any other suggestions? I think your approach is good. Do these PMDAs run as root, pcp user, or something else? If pcp user, have you had any success with those earlier experiments with pmie auto-restarting timed out PMDAs? (not a general solution, I know, just want to know if there's any new info there - thanks) > This has > started to occur more and more for us as we develop pmdas that interact > with systems that may introduce delays that we cannot control. *nod* - I remember having this issue with extracting NFS mount point usage stats at one production site; once identified and resolved, and using the background thread approach, stability was achieved (even on systems under significant io+net+mem+cpu load 24x7). So based on that past experience, I think your approach will prove sound. cheers. -- Nathan From myllynen@redhat.com Fri May 8 02:03:45 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 2FCA17F3F for ; Fri, 8 May 2015 02:03:45 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id B1DCDAC004 for ; Fri, 8 May 2015 00:03:44 -0700 (PDT) X-ASG-Debug-ID: 1431068619-04cb6c1cc7596000001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 9jtI3hnuD4hHl7AV (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 08 May 2015 00:03:40 -0700 (PDT) X-Barracuda-Envelope-From: myllynen@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4873dON019725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 8 May 2015 03:03:39 -0400 Received: from mmyllyne.csb (vpn1-4-20.ams2.redhat.com [10.36.4.20]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4873aJU014276 for ; Fri, 8 May 2015 03:03:38 -0400 Message-ID: <554C5FC8.5010304@redhat.com> Date: Fri, 08 May 2015 10:03:36 +0300 From: Marko Myllynen Reply-To: myllynen@redhat.com Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes References: <878ud0kneb.fsf@redhat.com> X-ASG-Orig-Subj: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes In-Reply-To: <878ud0kneb.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1431068620 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi, On 2015-05-08 01:56, Lukas Berk wrote: > Author: Lukas Berk > > Wrap pcp-pmda-rpm and pcp-gui with proper %if checks > > pcp-pmda-rpm and pcp-gui aren't built on some platforms, > wrapping them with proper checks so it doesn't fail on other platforms now that you're working with packaging, are there any chances to separate pmdumptext from pcp-gui so that fewer dependencies would be pulled in when installing pmdumptext? ldd indicates that QtCore is needed by pmdumptext (not sure why?) but otherwise pmdumptext has much shorter list of DSO dependencies that pmchart so it might make sense to separate them. Thanks, -- Marko Myllynen From kenj@internode.on.net Fri May 8 02:07:44 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 5393B7F4E for ; Fri, 8 May 2015 02:07:44 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id CEBB6AC003 for ; Fri, 8 May 2015 00:07:43 -0700 (PDT) X-ASG-Debug-ID: 1431068859-04cb6c1cc7596200001-S8gJnT Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id ypxeeOXNpfEX8Ck2 for ; Fri, 08 May 2015 00:07:40 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.129 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DeDgBnYExVPD1qLHlcgw5UXoZMwQOGBwQCAoE8TQEBAQEBAQcBAQEBQT9BBYNaAQEBBAgCMBwjDAEDAgYDDgMEAQEoBxkgCgMJCAIEEwsFiBvHOAEBAQcBAQEBHos6hQUHBoQnBZI5cIMrnROEKywxgkYBAQE Received: from ppp121-44-106-61.lns20.syd4.internode.on.net (HELO bozohorize) ([121.44.106.61]) by ipmail06.adl2.internode.on.net with ESMTP; 08 May 2015 16:37:07 +0930 From: "Ken McDonell" To: "'Mark Goodwin'" Cc: References: <878ud0kneb.fsf@redhat.com> <554C097F.4020406@redhat.com> In-Reply-To: <554C097F.4020406@redhat.com> Subject: RE: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes Date: Fri, 8 May 2015 17:07:02 +1000 X-ASG-Orig-Subj: RE: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes Message-ID: <016b01d0895d$97de5a80$c79b0f80$@internode.on.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQNIdW340TR8SaOKohzDp83/YqZW1QK0vkZTmmwe0WA= Content-Language: en-au X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1431068860 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, THREAD_INDEX X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18719 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header > -----Original Message----- > From: Mark Goodwin [mailto:mgoodwin@redhat.com] > Sent: Friday, 8 May 2015 10:55 AM > To: Ken McDonell > Cc: pcp@oss.sgi.com > Subject: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes > > Ken, if you have a minute could you pull this fix from Lukas and check it builds > and installs OK on that OpenSuSE13.2 vm of yours? (or give me access?) === CentOS 6.5 (vm14) build OK including pcp-pmda-rpm install mostly OK, except for unrelated (?) .NeedRebuild botch below kenj@vm14:~/src/pcp$ sudo rpm -U `ls pcp-3.10.5/build/rpm/*.rpm | sed -e '/src.rpm/d'` Waiting for pmcd to terminate ... Rebuilding PMNS ... Starting pmcd ... Starting pmlogger ... Waiting for pmproxy to terminate ... Starting pmproxy ... rm: cannot remove `.NeedRebuild': No such file or directory Waiting for pmwebd to terminate ... Starting pmwebd ... Waiting for pmmgr to terminate ... Starting pmmgr ... === openSuSE 12.1 (vm02) build OK ... no pcp-pmda-rpm here because no rpm-devel and no pcp-webapi because no libmicrohttpd-devel install OK except for postfix-perl-scripts problem AND problem still with pcp-monitor needing pcp-webapi error: Failed dependencies: pcp-webapi is needed by pcp-monitor-3.10.5-1.i586 postfix-perl-scripts is needed by pcp-pmda-postfix-3.10.5-1.i586 === openSuSE 13.1 (vm24) build OK ... no pcp-pmda-rpm here because no rpm-devel install OK except for postfix-perl-scripts problem error: Failed dependencies: postfix-perl-scripts is needed by pcp-pmda-postfix-3.10.5-1.i586 From nscott@redhat.com Fri May 8 02:10:55 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id B32CB7F50 for ; Fri, 8 May 2015 02:10:55 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 956728F8073 for ; Fri, 8 May 2015 00:10:55 -0700 (PDT) X-ASG-Debug-ID: 1431069053-04cbb056b45f3ee0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id ORVp2iHLeSH2jJvL (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 08 May 2015 00:10:53 -0700 (PDT) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t487Aq3X004689; Fri, 8 May 2015 03:10:52 -0400 Date: Fri, 8 May 2015 03:10:52 -0400 (EDT) From: Nathan Scott Reply-To: Nathan Scott To: myllynen@redhat.com Cc: pcp@oss.sgi.com Message-ID: <1501708647.15458472.1431069052819.JavaMail.zimbra@redhat.com> In-Reply-To: <554C5FC8.5010304@redhat.com> References: <878ud0kneb.fsf@redhat.com> <554C5FC8.5010304@redhat.com> Subject: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.64.50.253] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF37 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp-updates spin-rawhide, docs, pcp.spec.in fixes Thread-Index: 3ovbHTpw7UsR7UESxcYIkOG//uZxig== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1431069053 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18719 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > Hi, > > On 2015-05-08 01:56, Lukas Berk wrote: > > Author: Lukas Berk > > > > Wrap pcp-pmda-rpm and pcp-gui with proper %if checks > > > > pcp-pmda-rpm and pcp-gui aren't built on some platforms, > > wrapping them with proper checks so it doesn't fail on other platforms > > now that you're working with packaging, are there any chances to > separate pmdumptext from pcp-gui so that fewer dependencies would be > pulled in when installing pmdumptext? (good idea & definitely worth a look - I'd forgotten all about that) > ldd indicates that QtCore is > needed by pmdumptext (not sure why?) It uses libpcp_qmc (our Qt metrics class), and QString's, QTextStream, and other Qt classes. > but otherwise pmdumptext has much > shorter list of DSO dependencies that pmchart so it might make sense to > separate them. Yep. cheers. -- Nathan From kenj@internode.on.net Fri May 8 03:35:53 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 1CAE97F37 for ; Fri, 8 May 2015 03:35:53 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 0FCF58F8050 for ; Fri, 8 May 2015 01:35:49 -0700 (PDT) X-ASG-Debug-ID: 1431074146-04cb6c1cc7597e70001-S8gJnT Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id gS7mC0QjRL2e7F1B for ; Fri, 08 May 2015 01:35:47 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.129 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AtKABcdExVPD1qLHlcgw5UXoZMwQmGBwQCAoE8TQEBAQEBAQcBAQEBQAE/QQECAoNbAQEECAIwHCMNAwIGA0YZIAoUAgQBHQWIG8dXAQEIAgEfizqFBQeELQWSOXCDK50ThCssMYJGAQEB Received: from ppp121-44-106-61.lns20.syd4.internode.on.net (HELO bozohorize) ([121.44.106.61]) by ipmail06.adl2.internode.on.net with ESMTP; 08 May 2015 18:05:45 +0930 From: "Ken McDonell" To: "'Nathan Scott'" , Cc: References: <878ud0kneb.fsf@redhat.com> <554C5FC8.5010304@redhat.com> <1501708647.15458472.1431069052819.JavaMail.zimbra@redhat.com> In-Reply-To: <1501708647.15458472.1431069052819.JavaMail.zimbra@redhat.com> Subject: RE: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes Date: Fri, 8 May 2015 18:35:42 +1000 X-ASG-Orig-Subj: RE: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes Message-ID: <017901d08969$f98c7e90$eca57bb0$@internode.on.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQNIdW340TR8SaOKohzDp83/YqZW1QHcK842AWPui8+aZ+avEA== Content-Language: en-au X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1431074146 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18721 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== Another problem ... this time one of my Centos 5.5 (vm25) system error: Failed dependencies: pcp-pmda-gluster is needed by pcp-collector-3.10.5-6.x86_64 pcp-pmda-zswap is needed by pcp-collector-3.10.5-6.x86_64 pcp-pmda-unbound is needed by pcp-collector-3.10.5-6.x86_64 pcp-pmda-gluster is needed by pcp-compat-3.10.5-6.x86_64 pcp-pmda-zswap is needed by pcp-compat-3.10.5-6.x86_64 pcp-pmda-unbound is needed by pcp-compat-3.10.5-6.x86_64 pcp-system-tools is needed by pcp-compat-3.10.5-6.x86_64 pcp-system-tools is needed by pcp-monitor-3.10.5-6.x86_64 pcp-webapi is needed by pcp-monitor-3.10.5-6.x86_64 postfix-perl-scripts is needed by pcp-pmda-postfix-3.10.5-6.x86_64 HAVE_PYTHON is false here ... so this PYPMDAS = gluster zswap unbound never happens and these pmdas are not built. And the spec file excludes pcp-system-tools for the same reason. From kenj@internode.on.net Fri May 8 06:23:17 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 6F41B7F3F for ; Fri, 8 May 2015 06:23:17 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 627628F8040 for ; Fri, 8 May 2015 04:23:17 -0700 (PDT) X-ASG-Debug-ID: 1431084193-04cbb056b25fb020001-S8gJnT Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id BkZWFICmwgsRvd5V for ; Fri, 08 May 2015 04:23:13 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.129 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AtKABpm0xVPD1qLHlcgw5UXoZMwQ2GBwQCAoFATQEBAQEBAQcBAQEBQAE/QQECAoNbAQEECAIwHCMNAwIGA0YZIAoUAgQBHQWIG8dUAQEIAgEfizqFBQeELQWSOXCDK50ThCssMYJGAQEB Received: from ppp121-44-106-61.lns20.syd4.internode.on.net (HELO bozohorize) ([121.44.106.61]) by ipmail06.adl2.internode.on.net with ESMTP; 08 May 2015 20:53:11 +0930 From: "Ken McDonell" To: "'Nathan Scott'" , Cc: References: <878ud0kneb.fsf@redhat.com> <554C5FC8.5010304@redhat.com> <1501708647.15458472.1431069052819.JavaMail.zimbra@redhat.com> <017901d08969$f98c7e90$eca57bb0$@internode.on.net> In-Reply-To: <017901d08969$f98c7e90$eca57bb0$@internode.on.net> Subject: RE: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes Date: Fri, 8 May 2015 21:23:08 +1000 X-ASG-Orig-Subj: RE: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes Message-ID: <017b01d08981$5d40f8f0$17c2ead0$@internode.on.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQNIdW340TR8SaOKohzDp83/YqZW1QHcK842AWPui88BzXln1ZpZqrvQ Content-Language: en-au X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1431084193 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18724 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== Yet another problem: qshape is in the postfix rpm in CentOS 5.11. I think the Requires: clause in the spec file is doomed for pcp-pmda-postfix! From myllynen@redhat.com Fri May 8 09:15:17 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id D4E6229DFB for ; Fri, 8 May 2015 09:15:17 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 5932CAC002 for ; Fri, 8 May 2015 07:15:14 -0700 (PDT) X-ASG-Debug-ID: 1431094512-04cbb056b4600a30001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id DFwYprZpGkLQQYX5 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 08 May 2015 07:15:13 -0700 (PDT) X-Barracuda-Envelope-From: myllynen@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 04A43A10D2; Fri, 8 May 2015 14:15:12 +0000 (UTC) Received: from mmyllyne.csb (vpn1-4-20.ams2.redhat.com [10.36.4.20]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t48EF99m012821; Fri, 8 May 2015 10:15:10 -0400 Message-ID: <554CC4ED.4090209@redhat.com> Date: Fri, 08 May 2015 17:15:09 +0300 From: Marko Myllynen Reply-To: myllynen@redhat.com Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ken McDonell , "Frank Ch. Eigler" CC: pcp@oss.sgi.com Subject: Re: [pcp] Calculated/derived metrics? References: <5534C680.2020709@redhat.com> <493537984.3276058.1429528962326.JavaMail.zimbra@redhat.com> <5534EBA8.4030509@redhat.com> <1644393599.3651017.1429563442835.JavaMail.zimbra@redhat.com> <55364606.1000503@redhat.com> <55472B40.7050800@redhat.com> <5547DE11.5050800@internode.on.net> <5549E4CD.5000408@redhat.com> <554AFE4E.80000@internode.on.net> <554BEB16.7030208@internode.on.net> X-ASG-Orig-Subj: Re: [pcp] Calculated/derived metrics? In-Reply-To: <554BEB16.7030208@internode.on.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1431094512 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi, On 2015-05-08 01:45, Ken McDonell wrote: > On 08/05/15 06:35, Frank Ch. Eigler wrote: >> ... >> Is the rate() derived-metrics function applicable here? > > If I understand Marko's requirement he'd like to get something close to > the I/O rate of the process over its life, rather than over the last > time period (hotproc.io.write_bytes by itself will give you the latter, > as will rate(hotproc.io.write_bytes) in a derived metric). yes, I think there are certainly use cases for both, in this particular case I was thinking checking e.g. with pmval or pmdumptext "hot" processes' I/O activity for an application which does its I/O in bursts, with rate() most often the result would be zero but with value() it'd give instantly some sort of general idea what app has been up to I/O-wise (so it'd be a perfect match for this derived convenience metric). Thanks, -- Marko Myllynen From myllynen@redhat.com Fri May 8 09:18:06 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 369AB29DFB for ; Fri, 8 May 2015 09:18:06 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 0EBD08F8033 for ; Fri, 8 May 2015 07:18:02 -0700 (PDT) X-ASG-Debug-ID: 1431094678-04bdf06322611d80001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id OPtbHqgpalr2Ml1Y (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 08 May 2015 07:17:59 -0700 (PDT) X-Barracuda-Envelope-From: myllynen@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 6F67CB8130; Fri, 8 May 2015 14:17:58 +0000 (UTC) Received: from mmyllyne.csb (vpn1-4-20.ams2.redhat.com [10.36.4.20]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t48EHu2X021545; Fri, 8 May 2015 10:17:57 -0400 Message-ID: <554CC594.20300@redhat.com> Date: Fri, 08 May 2015 17:17:56 +0300 From: Marko Myllynen Reply-To: myllynen@redhat.com Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ken McDonell , pcp@oss.sgi.com Subject: Re: [pcp] Calculated/derived metrics? References: <5534C680.2020709@redhat.com> <493537984.3276058.1429528962326.JavaMail.zimbra@redhat.com> <5534EBA8.4030509@redhat.com> <1644393599.3651017.1429563442835.JavaMail.zimbra@redhat.com> <55364606.1000503@redhat.com> <55472B40.7050800@redhat.com> <5547DE11.5050800@internode.on.net> <5549E4CD.5000408@redhat.com> <554AFE4E.80000@internode.on.net> <554B3E8F.3080904@redhat.com> <554C1F23.1090609@internode.on.net> X-ASG-Orig-Subj: Re: [pcp] Calculated/derived metrics? In-Reply-To: <554C1F23.1090609@internode.on.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1431094678 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi, On 2015-05-08 05:27, Ken McDonell wrote: > On 07/05/15 20:29, Marko Myllynen wrote: >> ... >>> And I'm not sure why the /100 is required, could you please explain >>> that part? >> >> kernel.all.uptime is in seconds but hotproc.psinfo.start_time is in >> jiffies and although jiffies-to-seconds is not necessarily a trivial >> operation [1], /100 seemed to provide "close enough" results during my >> tests. ... > > Be careful. We (in PCPland) try very hard to avoid platform-variant and > decade-variant units of measure ... blocks and hz and jiffies are all in > this bag. > > So no matter what units the base instrumentation is in, the PMDA is > responsible for translating it to something useful and invariant ... > like seconds in this case. > > But unfortunately in this case the PMDA implementor says the metrics are > seconds, but they are not (see the example below) ... this is a BUG .. ok, I admit I didn't pay that much attention to units, it looked like the jiffies value under /proc so I just went ahead with the calculation. > the PMDA should return hotproc.psinfo.start_time either /100 and call it > seconds or *10 and call it msec (and increase it to 64-bits in this case). > > If this was fixed you would not need the /100. I'll file a bug next week if nobody beats me. >> It would be nice to be able to write this as: >> >> mytest.divisor = hotproc.psinfo.start_time - kernel.all.uptime >> mytest.marko = hotproc.psinfo.rss / mytest.divisor > > I don't think nested definitions are going to happen ... the code behind > this is already pretty complex ... but I could entertain a pmie-style > macro definition and substitution that would achieve the same effect. That'd be great. One more thing that occurred to me that might be useful, especially if we were to create that "library of derived metrics" or such, I'd like to do this in my own derived metric configuration file: $include /etc/pcp/derived-metrics.conf mytest.test = ... mytest.foo = ... Mostly a matter of convenience again and certainly nothing critical but if the provided "library of derived metrics" would grow over time, it might also make sense to split it to separate files and then use includes there, too. Thanks, -- Marko Myllynen From fche@redhat.com Fri May 8 13:16:19 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 80B5C7F54 for ; Fri, 8 May 2015 13:16:19 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 1E0EBAC006 for ; Fri, 8 May 2015 11:16:18 -0700 (PDT) X-ASG-Debug-ID: 1431108974-04cb6c1cc85a86a0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id VjAJvakCHYoupiDc (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 08 May 2015 11:16:15 -0700 (PDT) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t48IGB0H021991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 8 May 2015 14:16:11 -0400 Received: from fche.csb (vpn-226-104.phx2.redhat.com [10.3.226.104]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t48IGAE2017893; Fri, 8 May 2015 14:16:11 -0400 Received: by fche.csb (Postfix, from userid 2569) id 085D4586B5; Fri, 8 May 2015 14:16:08 -0400 (EDT) Date: Fri, 8 May 2015 14:16:08 -0400 From: "Frank Ch. Eigler" To: Marko Myllynen Cc: Ken McDonell , pcp@oss.sgi.com Subject: Re: [pcp] Calculated/derived metrics? Message-ID: <20150508181608.GA3195@redhat.com> X-ASG-Orig-Subj: Re: [pcp] Calculated/derived metrics? References: <5534EBA8.4030509@redhat.com> <1644393599.3651017.1429563442835.JavaMail.zimbra@redhat.com> <55364606.1000503@redhat.com> <55472B40.7050800@redhat.com> <5547DE11.5050800@internode.on.net> <5549E4CD.5000408@redhat.com> <554AFE4E.80000@internode.on.net> <554BEB16.7030208@internode.on.net> <554CC4ED.4090209@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <554CC4ED.4090209@redhat.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1431108974 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - On Fri, May 08, 2015 at 05:15:09PM +0300, Marko Myllynen wrote: > [...] > >> Is the rate() derived-metrics function applicable here? > > > > If I understand Marko's requirement he'd like to get something close to > > the I/O rate of the process over its life, rather than over the last > > time period (hotproc.io.write_bytes by itself will give you the latter, > > as will rate(hotproc.io.write_bytes) in a derived metric). > > yes, I think there are certainly use cases for both, in this particular > case I was thinking checking e.g. with pmval or pmdumptext "hot" > processes' I/O activity for an application which does its I/O in bursts, > with rate() most often the result would be zero but with value() it'd > give instantly some sort of general idea what app has been up to > I/O-wise (so it'd be a perfect match for this derived convenience metric). So you still want rate, but smoothed or over a longer time period. A counter-value() operator seems like a good expedient, but a longer term and more robust (overflow-aware etc.) way would be to have a rate(metric,'10 minutes') or exponential_smooth(rate(metric),0.9) types of things. (Probably this and the pmie expression syntaxes should be unified.) - FChE From minnus@buffalo.edu Fri May 8 13:36:13 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 6B1D37F54 for ; Fri, 8 May 2015 13:36:13 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 623D48F8037 for ; Fri, 8 May 2015 11:36:10 -0700 (PDT) X-ASG-Debug-ID: 1431110168-04cb6c1cc95a8e10001-S8gJnT Received: from mtareserve1.acsu.buffalo.edu (mtareserve3.acsu.buffalo.edu [128.205.7.163]) by cuda.sgi.com with ESMTP id e8cE7FLuEHzOvapJ for ; Fri, 08 May 2015 11:36:08 -0700 (PDT) X-Barracuda-Envelope-From: minnus@buffalo.edu X-Barracuda-Apparent-Source-IP: 128.205.7.163 Received: from localmailf.acsu.buffalo.edu (localmailf.acsu.buffalo.edu [128.205.4.17]) by mtareserve1.acsu.buffalo.edu (Postfix) with ESMTP id E7F809A57; Fri, 8 May 2015 14:36:07 -0400 (EDT) Received: from localmailf.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 602528008B; Fri, 8 May 2015 14:36:12 -0400 (EDT) Received: from localmailf.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailf.acsu.buffalo.edu (Postfix) with ESMTP id 3E49A8009D; Fri, 8 May 2015 14:36:12 -0400 (EDT) Received: from smtp.buffalo.edu (smtp3.acsu.buffalo.edu [128.205.5.226]) by localmailf.acsu.buffalo.edu (Prefixe) with ESMTP id 331638008B; Fri, 8 May 2015 14:36:12 -0400 (EDT) Received: from [128.205.40.46] (slash.ccr.buffalo.edu [128.205.40.46]) (Authenticated sender: minnus@buffalo.edu) by smtp.buffalo.edu (Postfix) with ESMTPSA id A6AEA77FEC; Fri, 8 May 2015 14:36:07 -0400 (EDT) Message-ID: <554D01FD.4060000@buffalo.edu> Date: Fri, 08 May 2015 14:35:41 -0400 From: Martins Innus User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ken McDonell , myllynen@redhat.com, pcp@oss.sgi.com Subject: Re: [pcp] Calculated/derived metrics? References: <5534C680.2020709@redhat.com> <493537984.3276058.1429528962326.JavaMail.zimbra@redhat.com> <5534EBA8.4030509@redhat.com> <1644393599.3651017.1429563442835.JavaMail.zimbra@redhat.com> <55364606.1000503@redhat.com> <55472B40.7050800@redhat.com> <5547DE11.5050800@internode.on.net> <5549E4CD.5000408@redhat.com> <554AFE4E.80000@internode.on.net> <554B3E8F.3080904@redhat.com> <554C1F23.1090609@internode.on.net> X-ASG-Orig-Subj: Re: [pcp] Calculated/derived metrics? In-Reply-To: <554C1F23.1090609@internode.on.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-PM-EL-Spam-Prob: : 8% X-Barracuda-Connect: mtareserve3.acsu.buffalo.edu[128.205.7.163] X-Barracuda-Start-Time: 1431110168 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18732 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Ken, On 5/7/15 10:27 PM, Ken McDonell wrote: > > > But unfortunately in this case the PMDA implementor says the metrics > are seconds, but they are not (see the example below) ... this is a > BUG .. the PMDA should return hotproc.psinfo.start_time either /100 > and call it seconds or *10 and call it msec (and increase it to > 64-bits in this case). > > # pminfo -f proc.psinfo.start_time | sed -e 's/.* value //' | sort -nr > | head -2 ; pminfo -f kernel.all.uptime > 9086825 > 9086825 > > kernel.all.uptime > value 90868 So I started looking into this. Looks like this has been there forever (hotproc just uses the same semantics defined in proc). But I have added other proc metrics that may need fixing as well. While the change for this metric (to ms and 64 bit to match the rest of the "time" metrics in proc) seems correct and straightforward, I have some confusion on the types in general for some of the proc time metrics. Apologies for the long description, and maybe I have a mistake somewhere. If we were to model this change after a similar metric (on Centos 6 x86_64): proc.psinfo.utime PMID: 3.8.13 = 12591117 = 0xc0200d Data Type: 64-bit unsigned int InDom: 3.9 0xc00009 Semantics: counter Units: millisec Which is defined as (in pmda.c): /* proc.psinfo.utime */ { NULL, { PMDA_PMID(CLUSTER_PID_STAT,13), KERNEL_ULONG, PROC_INDOM, PM_SEM_COUNTER, PMDA_PMUNITS(0,1,0,0,PM_TIME_MSEC,0) } }, where KERNEL_ULONG comes from ../linux/convert.h: #if defined(HAVE_64BIT_LONG) #define KERNEL_ULONG PM_TYPE_U64 #define _pm_assign_ulong(atomp, val) do { (atomp)->ull = (val); } while (0) #else #define KERNEL_ULONG PM_TYPE_U32 #define _pm_assign_ulong(atomp, val) do { (atomp)->ul = (val); } while (0) #endif Where "man 5 proc" says about the source type: utime %lu Which on this platform should be 64 bit. But the assignment from the source proc data does this explicit 32bit cast (pmda.c): case PROC_PID_STAT_UTIME: /* proc.psinfo.utime */ case PROC_PID_STAT_STIME: /* proc.psinfo.stime */ case PROC_PID_STAT_CUTIME: /* proc.psinfo.cutime */ case PROC_PID_STAT_CSTIME: /* proc.psinfo.cstime */ /* unsigned jiffies converted to unsigned msecs */ f = _pm_getfield(entry->stat_buf, idp->item); if (f == NULL) return 0; ul = (__uint32_t)strtoul(f, &tail, 0); _pm_assign_ulong(atom, 1000 * (double)ul / hz); break; Since i think the source value is centi-seconds (on this platform anyway), that cast will cause truncation in less than a cpuyear if my math is correct. So even though: proc.psinfo.utime is defined as 64 bits, "ul" in the pmda is defined as "unsigned long" (64 bits) and the _pm_assign_ulong macro assigns to ull, it will never report a value larger than max(__uint32_t)*1000/hz, due to the __uint32_t cast. It appears the solution is to do a conditional cast based on HAVE_64BIT_LONG. So augment the above to something like: #if defined(HAVE_64BIT_LONG) #define KERNEL_ULONG PM_TYPE_U64 #define _pm_assign_ulong(atomp, val) do { (atomp)->ull = (val); } while (0) #define __pm_kernel_ulong_t __uint64_t #else #define KERNEL_ULONG PM_TYPE_U32 #define _pm_assign_ulong(atomp, val) do { (atomp)->ul = (val); } while (0) #define __pm_kernel_ulong_t __uint32_t #endif and then change the cast to : ul = (__pm_kernel_ulong_t)strtoul(f, &tail, 0); There are a couple other spots where this could be done in the pmda as well. Does that sound reasonable, or some other cleanup with respect to data width? Martins From kenj@internode.on.net Fri May 8 16:06:22 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id DA4937F54 for ; Fri, 8 May 2015 16:06:22 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id CBFD1304039 for ; Fri, 8 May 2015 14:06:22 -0700 (PDT) X-ASG-Debug-ID: 1431119175-04cbb056b260bd20001-S8gJnT Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id ZcpOdJ6FuxsDpoJA for ; Fri, 08 May 2015 14:06:15 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2A/BwB7JE1VPIl3LHlcgw5UXsZmCoV/BAICgTNNAQEBAQEBBwEBAQFBP4QgAQEBBAEBAQUCHhIcGAsMAQMCBgMRBAEBKAcZDhIKAwkIAgQBEgsFiBsOyHsBAQEBAQUBAQEBAR2LOoJrghoHBoQnBZI7cIMsnRaELCwxgkYBAQE Received: from ppp121-44-119-137.lns20.syd4.internode.on.net (HELO bozohorize) ([121.44.119.137]) by ipmail06.adl6.internode.on.net with ESMTP; 09 May 2015 06:36:14 +0930 From: "Ken McDonell" To: "'Nathan Scott'" , Cc: References: <878ud0kneb.fsf@redhat.com> <554C5FC8.5010304@redhat.com> <1501708647.15458472.1431069052819.JavaMail.zimbra@redhat.com> <017901d08969$f98c7e90$eca57bb0$@internode.on.net> In-Reply-To: <017901d08969$f98c7e90$eca57bb0$@internode.on.net> Subject: RE: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes Date: Sat, 9 May 2015 07:06:08 +1000 X-ASG-Orig-Subj: RE: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes Message-ID: <000401d089d2$cf304910$6d90db30$@internode.on.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQNIdW340TR8SaOKohzDp83/YqZW1QHcK842AWPui88BzXln1ZpaTetw Content-Language: en-au X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1431119175 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18734 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== I have a fix for this ... just testing now across all my rpm-based QA systems ... this could take a day or so to complete > -----Original Message----- > From: pcp-bounces@oss.sgi.com [mailto:pcp-bounces@oss.sgi.com] On Behalf > Of Ken McDonell > Sent: Friday, 8 May 2015 6:36 PM > To: 'Nathan Scott'; myllynen@redhat.com > Cc: pcp@oss.sgi.com > Subject: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes > > Another problem ... this time one of my Centos 5.5 (vm25) system > > error: Failed dependencies: > pcp-pmda-gluster is needed by pcp-collector-3.10.5-6.x86_64 > pcp-pmda-zswap is needed by pcp-collector-3.10.5-6.x86_64 > pcp-pmda-unbound is needed by pcp-collector-3.10.5-6.x86_64 > pcp-pmda-gluster is needed by pcp-compat-3.10.5-6.x86_64 > pcp-pmda-zswap is needed by pcp-compat-3.10.5-6.x86_64 > pcp-pmda-unbound is needed by pcp-compat-3.10.5-6.x86_64 > pcp-system-tools is needed by pcp-compat-3.10.5-6.x86_64 > pcp-system-tools is needed by pcp-monitor-3.10.5-6.x86_64 > pcp-webapi is needed by pcp-monitor-3.10.5-6.x86_64 > postfix-perl-scripts is needed by pcp-pmda-postfix-3.10.5-6.x86_64 > > HAVE_PYTHON is false here ... so this > > PYPMDAS = gluster zswap unbound > > never happens and these pmdas are not built. > > And the spec file excludes pcp-system-tools for the same reason. > > _______________________________________________ > pcp mailing list > pcp@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/pcp From kenj@internode.on.net Fri May 8 17:10:31 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 6DC3929DFB for ; Fri, 8 May 2015 17:10:31 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 576D2304039 for ; Fri, 8 May 2015 15:10:28 -0700 (PDT) X-ASG-Debug-ID: 1431123022-04cbb056b160cfb0001-S8gJnT Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id H3GD3EEK06QH8Iwp for ; Fri, 08 May 2015 15:10:22 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BuBwBTM01VPIl3LHlcgw5UXoZMwByGBwQCAoEzTQEBAQEBAQcBAQEBQAE/hCABAQEECAIeLiMMAQMCBgMRBAEBKAcZIAoDCQgCBAESCwWIG8kNAQEBAQEBAQECAQEBAQEBAQEBGYs6hQUHBoQnBZI7cIETgTxdiCeUb4QsLDGCRgEBAQ Received: from ppp121-44-119-137.lns20.syd4.internode.on.net (HELO bozohorize) ([121.44.119.137]) by ipmail06.adl6.internode.on.net with ESMTP; 09 May 2015 07:39:23 +0930 From: "Ken McDonell" To: "'Nathan Scott'" , Cc: References: <878ud0kneb.fsf@redhat.com> <554C5FC8.5010304@redhat.com> <1501708647.15458472.1431069052819.JavaMail.zimbra@redhat.com> <017901d08969$f98c7e90$eca57bb0$@internode.on.net> <000401d089d2$cf304910$6d90db30$@internode.on.net> In-Reply-To: <000401d089d2$cf304910$6d90db30$@internode.on.net> Subject: RE: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes Date: Sat, 9 May 2015 08:09:18 +1000 X-ASG-Orig-Subj: RE: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes Message-ID: <001201d089db$a1a877c0$e4f96740$@internode.on.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_01D08A2F.7354FCF0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQNIdW340TR8SaOKohzDp83/YqZW1QHcK842AWPui88BzXln1QG6acKNmkyJH3A= Content-Language: en-au X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1431123022 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18736 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== This is a multipart message in MIME format. ------=_NextPart_000_0013_01D08A2F.7354FCF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: pcp-bounces@oss.sgi.com [mailto:pcp-bounces@oss.sgi.com] On Behalf > Of Ken McDonell > Sent: Saturday, 9 May 2015 7:06 AM > To: 'Nathan Scott'; myllynen@redhat.com > Cc: pcp@oss.sgi.com > Subject: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes > > I have a fix for this ... just testing now across all my rpm-based QA systems ... > this could take a day or so to complete So, I've hit the wall here. On two systems now (of the 5 I've tried so far) the rpm packaging has failed in a way I've never seen before (see attachment for the tail of the Logs/pcp file) and on the other systems it works. Can anyone shed light on this, or help diagnose or guide triage? What's strange is that this appears to be in the pcp-testsuite part of the packaging and I've made no changes to the spec file in that area. ------=_NextPart_000_0013_01D08A2F.7354FCF0 Content-Type: text/plain; name="pcp.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pcp.txt" ...=0A= + /usr/lib/rpm/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump=0A= Processing files: pcp-3.10.5-7.i386=0A= Finding Provides: /usr/lib/rpm/find-provides=0A= Finding Requires: = /home/kenj/src/pcp/pcp-3.10.5/pcp-3.10.5/build/rpm/filter-requires -v = redhat -f 017 -r 0 /usr/lib/rpm/find-requires=0A= Provides: pmcd pmda_jbd2.so pmda_jbd2.so(JBD2) pmda_linux.so = pmda_linux.so(LINUX) pmda_mmv.so pmda_mmv.so(MMV) pmda_pmcd.so = pmda_pmcd.so(PMCD) pmda_proc.so pmda_proc.so(PROC) pmda_xfs.so = pmda_xfs.so(XFS) pmie pmlogger pmproxy=0A= Requires(interp): /bin/sh /bin/sh /bin/sh=0A= Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <=3D 4.0-1 = rpmlib(CompressedFileNames) <=3D 3.0.4-1=0A= Requires(pre): /bin/sh=0A= Requires(post): /bin/sh=0A= Requires(preun): /bin/sh=0A= Requires: /bin/sh libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) = libc.so.6(GLIBC_2.1.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.14) = libc.so.6(GLIBC_2.15) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.3) = libc.so.6(GLIBC_2.3.4) libc.so.6(GLIBC_2.4) libc.so.6(GLIBC_2.9) = libdl.so.2 libdl.so.2(GLIBC_2.0) libdl.so.2(GLIBC_2.1) libm.so.6 = libm.so.6(GLIBC_2.0) libm.so.6(GLIBC_2.1) libpcp_gui.so.2 = libpcp_mmv.so.1 libpcp_pmda.so.3 libpcp.so.3 libpcp_trace.so.2 = libpthread.so.0 libpthread.so.0(GLIBC_2.0) libreadline.so.6=0A= Conflicts: pcp-pro < 2.2 librapi=0A= Obsoletes: pcp-gui-debuginfo=0A= Processing files: pcp-conf-3.10.5-7.i386=0A= Finding Provides: /usr/lib/rpm/find-provides=0A= Finding Requires: = /home/kenj/src/pcp/pcp-3.10.5/pcp-3.10.5/build/rpm/filter-requires -v = redhat -f 017 -r 0 /usr/lib/rpm/find-requires=0A= Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <=3D 4.0-1 = rpmlib(CompressedFileNames) <=3D 3.0.4-1=0A= Conflicts: pcp-libs < 3.9=0A= Processing files: pcp-libs-3.10.5-7.i386=0A= Finding Provides: /usr/lib/rpm/find-provides=0A= Finding Requires: = /home/kenj/src/pcp/pcp-3.10.5/pcp-3.10.5/build/rpm/filter-requires -v = redhat -f 017 -r 0 /usr/lib/rpm/find-requires=0A= Provides: libpcp_gui.so.2 libpcp_gui.so.2(PCP_GUI_2.0) = libpcp_import.so.1 libpcp_import.so.1(PCP_IMPORT_1.0) libpcp_mmv.so.1 = libpcp_mmv.so.1(PCP_MMV_1.0) libpcp_pmda.so.3 = libpcp_pmda.so.3(PCP_PMDA_3.0) libpcp_pmda.so.3(PCP_PMDA_3.1) = libpcp_pmda.so.3(PCP_PMDA_3.2) libpcp_pmda.so.3(PCP_PMDA_3.3) = libpcp_pmda.so.3(PCP_PMDA_3.4) libpcp.so.3 libpcp.so.3(PCP_3.0) = libpcp.so.3(PCP_3.1) libpcp.so.3(PCP_3.10) libpcp.so.3(PCP_3.11) = libpcp.so.3(PCP_3.2) libpcp.so.3(PCP_3.3) libpcp.so.3(PCP_3.4) = libpcp.so.3(PCP_3.5) libpcp.so.3(PCP_3.6) libpcp.so.3(PCP_3.7) = libpcp.so.3(PCP_3.8) libpcp.so.3(PCP_3.9) libpcp_trace.so.2 = libpcp_trace.so.2(PCP_TRACE_2.0)=0A= Requires(interp): /sbin/ldconfig /sbin/ldconfig=0A= Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <=3D 4.0-1 = rpmlib(CompressedFileNames) <=3D 3.0.4-1=0A= Requires(post): /sbin/ldconfig=0A= Requires(postun): /sbin/ldconfig=0A= Requires: ld-linux.so.2 ld-linux.so.2(GLIBC_2.3) libavahi-client.so.3 = libavahi-common.so.3 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) = libc.so.6(GLIBC_2.1.1) libc.so.6(GLIBC_2.1.2) libc.so.6(GLIBC_2.1.3) = libc.so.6(GLIBC_2.15) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.3) = libc.so.6(GLIBC_2.3.4) libc.so.6(GLIBC_2.4) libc.so.6(GLIBC_2.7) = libdl.so.2 libdl.so.2(GLIBC_2.0) libdl.so.2(GLIBC_2.1) libm.so.6 = libm.so.6(GLIBC_2.0) libm.so.6(GLIBC_2.1) libnspr4.so libnss3.so = libpcp.so.3 libpthread.so.0 libpthread.so.0(GLIBC_2.0) = libpthread.so.0(GLIBC_2.1) librt.so.1 librt.so.1(GLIBC_2.2) = libsasl2.so.2 libssl3.so=0A= Obsoletes: pcp < 3.0=0A= Processing files: pcp-libs-devel-3.10.5-7.i386=0A= Finding Provides: /usr/lib/rpm/find-provides=0A= Finding Requires: = /home/kenj/src/pcp/pcp-3.10.5/pcp-3.10.5/build/rpm/filter-requires -v = redhat -f 017 -r 0 /usr/lib/rpm/find-requires=0A= Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <=3D 4.0-1 = rpmlib(CompressedFileNames) <=3D 3.0.4-1=0A= Requires: /bin/sh=0A= Processing files: pcp-testsuite-3.10.5-7.i386=0A= Finding Provides: /usr/lib/rpm/find-provides=0A= Finding Requires: = /home/kenj/src/pcp/pcp-3.10.5/pcp-3.10.5/build/rpm/filter-requires -v = redhat -f 017 -r 0 /usr/lib/rpm/find-requires=0A= error: Dependency tokens must begin with alpha-numeric, '_' or '/': #=0A= /bin/sh=0A= /usr/bin/perl=0A= libc.so.6=0A= libc.so.6(GLIBC_2.0)=0A= libc.so.6(GLIBC_2.1)=0A= libc.so.6(GLIBC_2.1.3)=0A= libc.so.6(GLIBC_2.3.4)=0A= libc.so.6(GLIBC_2.4)=0A= libdl.so.2=0A= libgcc_s.so.1=0A= libgcc_s.so.1(GCC_3.0)=0A= libm.so.6=0A= libpcp_pmda.so.3=0A= libpcp.so.3=0A= libpthread.so.0=0A= libpthread.so.0(GLIBC_2.0)=0A= libQtCore.so.4=0A= libstdc++.so.6=0A= libstdc++.so.6(GLIBCXX_3.4)=0A= perl(Getopt::Long)=0A= perl(IO::Socket)=0A= perl(strict)=0A= =0A= error: Failed to find Requires:=0A= Provides: bigun.so true=0A= Requires(interp): /bin/sh /bin/sh=0A= Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <=3D 4.0-1 = rpmlib(CompressedFileNames) <=3D 3.0.4-1=0A= Requires(pre): /bin/sh=0A= Requires(post): /bin/sh=0A= Obsoletes: pcp-gui-testsuite=0A= =0A= =0A= RPM build errors:=0A= Dependency tokens must begin with alpha-numeric, '_' or '/': #=0A= /bin/sh=0A= /usr/bin/perl=0A= libc.so.6=0A= libc.so.6(GLIBC_2.0)=0A= libc.so.6(GLIBC_2.1)=0A= libc.so.6(GLIBC_2.1.3)=0A= libc.so.6(GLIBC_2.3.4)=0A= libc.so.6(GLIBC_2.4)=0A= libdl.so.2=0A= libgcc_s.so.1=0A= libgcc_s.so.1(GCC_3.0)=0A= libm.so.6=0A= libpcp_pmda.so.3=0A= libpcp.so.3=0A= libpthread.so.0=0A= libpthread.so.0(GLIBC_2.0)=0A= libQtCore.so.4=0A= libstdc++.so.6=0A= libstdc++.so.6(GLIBCXX_3.4)=0A= perl(Getopt::Long)=0A= perl(IO::Socket)=0A= perl(strict)=0A= =0A= Failed to find Requires:=0A= make: *** [pack_pcp] Error 1=0A= make: Leaving directory `/home/kenj/src/pcp/pcp-3.10.5/build/rpm'=0A= ------=_NextPart_000_0013_01D08A2F.7354FCF0-- From nscott@redhat.com Sun May 10 20:24:20 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 1BAE37F3F for ; Sun, 10 May 2015 20:24:20 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id AC9EDAC001 for ; Sun, 10 May 2015 18:24:16 -0700 (PDT) X-ASG-Debug-ID: 1431307451-04bdf06321657390001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id cb1QHecicwRuHI9M (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 10 May 2015 18:24:11 -0700 (PDT) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t4B1NuEf021085; Sun, 10 May 2015 21:23:56 -0400 Date: Sun, 10 May 2015 21:23:56 -0400 (EDT) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: PCP Message-ID: <1032017452.16231113.1431307436423.JavaMail.zimbra@redhat.com> In-Reply-To: <594407309.16229886.1431306491174.JavaMail.zimbra@redhat.com> Subject: Forwarding github issues to the list MIME-Version: 1.0 X-ASG-Orig-Subj: Forwarding github issues to the list Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.64.51.137] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF37 (Linux)/8.0.6_GA_5922) Thread-Topic: Forwarding github issues to the list Thread-Index: actTLxrjy80Fen6Pvw459YVlMMaJgw== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1431307451 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18774 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Hi Ken, Just realised that issues being reported via github are only being made visible to people who have explicitly signed up to get notified. It would seem to make sense to have the same forwarding that we've got in place for the Fedora, oss.sgi.com and Debian bug trackers, where notification is sent to the pcp list as well. Could we use your pcp@kenj.com.au account once more for this? thanks. -- Nathan From kenj@internode.on.net Sun May 10 21:38:54 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 1441B7F3F for ; Sun, 10 May 2015 21:38:54 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 09013304032 for ; Sun, 10 May 2015 19:38:50 -0700 (PDT) X-ASG-Debug-ID: 1431311924-04cbb056b16447a0001-S8gJnT Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id SLum2scNUmp8JSrI for ; Sun, 10 May 2015 19:38:44 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CAAQArFVBVPKEh0XYNT4NjXoMegy6+IAmBUIYDCgKBXBQBAQEBAQEBBgEBAQFBhGABAQQjFUABEAsYAgIFDAoLAgIJAwIBAgExFAYNAQUCAQG7FXCTAgEBAQEBAQEDAQEBAQEBARuBIYoYhQUHCoJegUUBBJAKhlGHaZFeg1WELF2BDIExCQEBAQ Received: from ppp118-209-33-161.lns20.mel4.internode.on.net (HELO [192.168.1.100]) ([118.209.33.161]) by ipmail05.adl6.internode.on.net with ESMTP; 11 May 2015 12:08:43 +0930 Message-ID: <55501632.8030501@internode.on.net> Date: Mon, 11 May 2015 12:38:42 +1000 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Nathan Scott CC: PCP Subject: Re: Forwarding github issues to the list References: <1032017452.16231113.1431307436423.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: Forwarding github issues to the list In-Reply-To: <1032017452.16231113.1431307436423.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1431311924 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18775 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 11/05/15 11:23, Nathan Scott wrote: > Hi Ken, > > Just realised that issues being reported via github are only > being made visible to people who have explicitly signed up to > get notified. It would seem to make sense to have the same > forwarding that we've got in place for the Fedora, oss.sgi.com > and Debian bug trackers, where notification is sent to the pcp > list as well. Could we use your pcp@kenj.com.au account once > more for this? Certainly. From nscott@redhat.com Mon May 11 01:54:17 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 22D807F3F for ; Mon, 11 May 2015 01:54:17 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 1AA14304048 for ; Sun, 10 May 2015 23:54:16 -0700 (PDT) X-ASG-Debug-ID: 1431327251-04cb6c1cc75e65f0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id Mv8wKLmkclDhCwqh (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 10 May 2015 23:54:11 -0700 (PDT) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t4B6s741012104; Mon, 11 May 2015 02:54:07 -0400 Date: Mon, 11 May 2015 02:54:07 -0400 (EDT) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: pcp@oss.sgi.com Message-ID: <1976100237.16484463.1431327247435.JavaMail.zimbra@redhat.com> In-Reply-To: <017b01d08981$5d40f8f0$17c2ead0$@internode.on.net> References: <878ud0kneb.fsf@redhat.com> <554C5FC8.5010304@redhat.com> <1501708647.15458472.1431069052819.JavaMail.zimbra@redhat.com> <017901d08969$f98c7e90$eca57bb0$@internode.on.net> <017b01d08981$5d40f8f0$17c2ead0$@internode.on.net> Subject: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.64.51.137] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF37 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp-updates spin-rawhide, docs, pcp.spec.in fixes Thread-Index: AQNIdW340TR8SaOKohzDp83/YqZW1QHcK842AWPui88BzXln1ZpZqrvQjaIwZjE= X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1431327251 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18779 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > Yet another problem: qshape is in the postfix rpm in CentOS 5.11. > > I think the Requires: clause in the spec file is doomed for > pcp-pmda-postfix! > Let's just shift this into fedora.spec (later) since its proving so problematic, and drop it for now. thanks Ken. -- Nathan From nscott@redhat.com Mon May 11 01:59:20 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id D548F7F3F for ; Mon, 11 May 2015 01:59:20 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id BD44E8F8039 for ; Sun, 10 May 2015 23:59:20 -0700 (PDT) X-ASG-Debug-ID: 1431327555-04bdf0632165ce20001-S8gJnT Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) by cuda.sgi.com with ESMTP id EeaGsJUcbqFdlLLA (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 10 May 2015 23:59:15 -0700 (PDT) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.39 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4B6xCRm010933; Mon, 11 May 2015 02:59:12 -0400 Date: Mon, 11 May 2015 02:59:12 -0400 (EDT) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: pcp@oss.sgi.com Message-ID: <1222832830.16485882.1431327552660.JavaMail.zimbra@redhat.com> In-Reply-To: <001201d089db$a1a877c0$e4f96740$@internode.on.net> References: <878ud0kneb.fsf@redhat.com> <554C5FC8.5010304@redhat.com> <1501708647.15458472.1431069052819.JavaMail.zimbra@redhat.com> <017901d08969$f98c7e90$eca57bb0$@internode.on.net> <000401d089d2$cf304910$6d90db30$@internode.on.net> <001201d089db$a1a877c0$e4f96740$@internode.on.net> Subject: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.64.51.137] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF37 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp-updates spin-rawhide, docs, pcp.spec.in fixes Thread-Index: AQNIdW340TR8SaOKohzDp83/YqZW1QHcK842AWPui88BzXln1QG6acKNmkyJH3CDiVxnzQ== X-Barracuda-Connect: mx6-phx2.redhat.com[209.132.183.39] X-Barracuda-Start-Time: 1431327555 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18779 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > [...] > So, I've hit the wall here. > > On two systems now (of the 5 I've tried so far) the rpm packaging has failed > in a way I've never seen before (see attachment for the tail of the Logs/pcp > file) and on the other systems it works. > > Can anyone shed light on this, or help diagnose or guide triage? > > What's strange is that this appears to be in the pcp-testsuite part of the > packaging and I've made no changes to the spec file in that area. > Not seeing this here on any of the RHEL, Fedora, or an OpenSUSE Makepkgs build I just tried (don't have f17 here though, where this failure case is if I'm reading the log correctly). The error message is kinda suggesting there's a stray '#' somewhere - but I can't find it on inspection of pcp.spec ... maybe modify filter-requires (build/rpm/filter-requires) to stash the input/output its seeing? Might contain further clues I guess. cheers. -- Nathan From kenj@internode.on.net Mon May 11 02:30:20 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id C861C7F3F for ; Mon, 11 May 2015 02:30:20 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 52600AC004 for ; Mon, 11 May 2015 00:30:20 -0700 (PDT) X-ASG-Debug-ID: 1431329413-04cbb056b4649190001-S8gJnT Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id CoO7BdtsHQmE2DDx for ; Mon, 11 May 2015 00:30:13 -0700 (PDT) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CDAQBxWVBVPKEh0XYNT4NjXoMegy6+JAmBUIYDCgKBWhQBAQEBAQEBBgEBAQFBhGABAQQjFUABEAsYAgIFFgsCAgkDAgECATEUBg0BBwEBuyNwkxsBAQEBAQEBAwEBAQEBAQEbgSGKGIQtWAeCaIFFAQSWW50chCxdgQSBQgEBAQ Received: from ppp118-209-33-161.lns20.mel4.internode.on.net (HELO [192.168.1.100]) ([118.209.33.161]) by ipmail05.adl6.internode.on.net with ESMTP; 11 May 2015 17:00:12 +0930 Message-ID: <55505A83.2080002@internode.on.net> Date: Mon, 11 May 2015 17:30:11 +1000 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Nathan Scott CC: pcp@oss.sgi.com Subject: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes References: <878ud0kneb.fsf@redhat.com> <554C5FC8.5010304@redhat.com> <1501708647.15458472.1431069052819.JavaMail.zimbra@redhat.com> <017901d08969$f98c7e90$eca57bb0$@internode.on.net> <000401d089d2$cf304910$6d90db30$@internode.on.net> <001201d089db$a1a877c0$e4f96740$@internode.on.net> <1222832830.16485882.1431327552660.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] pcp-updates spin-rawhide, docs, pcp.spec.in fixes In-Reply-To: <1222832830.16485882.1431327552660.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1431329413 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18780 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 11/05/15 16:59, Nathan Scott wrote: > ... > The error message is kinda suggesting there's a stray '#' somewhere - but > I can't find it on inspection of pcp.spec ... maybe modify filter-requires > (build/rpm/filter-requires) to stash the input/output its seeing? Might > contain further clues I guess. I don't think it is worth triaging ... my change works for me everywhere, and it was only the older rpm distros with some combination of optional bits not being built that appeared to be the trigger ... or perhaps pcp-testsuite now has so many files in it that it's blowing some limit. From mgoodwin@redhat.com Mon May 11 06:27:56 2015 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 68F1629DFB for ; Mon, 11 May 2015 06:27:56 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 3DE938F8039 for ; Mon, 11 May 2015 04:27:52 -0700 (PDT) X-ASG-Debug-ID: 1431343668-04bdf06320665730001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id FREd0yMjr99gAHXO (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 11 May 2015 04:27:49 -0700 (PDT) X-Barracuda-Envelope-From: mgoodwin@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 8DBFDCE0 for ; Mon, 11 May 2015 11:27:48 +0000 (UTC) Received: from [10.64.51.122] (vpn1-51-122.bne.redhat.com [10.64.51.122]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4BBRkxA025717 for ; Mon, 11 May 2015 07:27:47 -0400 Message-ID: <5550922F.5060705@redhat.com> Date: Mon, 11 May 2015 21:27:43 +1000 From: Mark Goodwin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: pcp Subject: pcp updates: merge kenj (spec and packaging fixes, qa, perl tweaks, more PM_ERR_BADSTORE) + Lukas (VERSION tweak, webjs, more spec fixes) Content-Type: text/plain; charset=windows-1252; format=flowed X-ASG-Orig-Subj: pcp updates: merge kenj (spec and packaging fixes, qa, perl tweaks, more PM_ERR_BADSTORE) + Lukas (VERSION tweak, webjs, more spec fixes) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1431343668 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 RPM spec and pcp-compat upgrade issues should all be fixed now. Changes committed to git://git.pcp.io/pcp.git master Ken McDonell (11): pmda.h: refine PMDA_PMID macro PM_ERR_BADSTORE: second round of cosmetic changes src/perl/PMDA/cvalue.c: another PM_ERR_* place src/perl/PMDA/Makefile.PL: Perl voodoo so that test.pl runs OK qa/771: (new) exercise test.pl/cvalue.c from the perl PMDA bindings src/perl/PMDA/.gitignore: cvalue executable is not interesting qa/admin/check-vm: add rpm pcp.spec.in: make Requires: platform specific qa/admin/check-vm: add platform specific sections build/rpm/pcp.spec.in: more conditional Requires: changes build/rpm/filter-requires: jeez louise! Lukas Berk (3): spin-rawhide: Extract version info from VERSION.pcp Fix location of pcp-webjs gitweb in the pcp guide Wrap pcp-pmda-rpm and pcp-gui with proper %if checks Mark Goodwin (1): Add pmiostat to the list of tools known to pmafm. build/rpm/filter-requires | 9 ++++++- build/rpm/pcp.spec.in | 51 +++++++++++++++++++++++++++++++++----------- man/html/guide.html | 2 - qa/771 | 36 +++++++++++++++++++++++++++++++ qa/GNUmakefile | 2 - qa/admin/check-vm | 26 +++++++++++++++++++--- qa/group | 1 qa/perl/GNUmakefile | 26 ++++++++++++++++++++++ qa/perl/GNUmakefile.install | 1 qa/perl/Makefile | 2 + scripts/spin-rawhide | 12 ++++++---- src/include/pcp/pmda.h | 8 +++++- src/libpcp/src/err.c | 15 ++++++++++++ src/perl/PMDA/.gitignore | 1 src/perl/PMDA/Makefile.PL | 17 ++++++++++++++ src/perl/PMDA/PMDA.pm | 26 +++++++++++++--------- src/perl/PMDA/cvalue.c | 44 ++++++++++++++++++++++++++----------- src/pmafm/pmafm.pcp | 2 - src/python/pmapi.c | 18 +++++++++------ 19 files changed, 243 insertions(+), 56 deletions(-) Details ... commit cc66d213c9ccc68557b3fbc2e101a9fac9ac7329 Author: Ken McDonell Date: Sat May 9 19:19:38 2015 +1000 build/rpm/filter-requires: jeez louise! Some versions of rpm-build (and at least this one rpm-build-4.10.3.1-3.fc18.x86_64), are pathologically broken in that their version of /usr/lib/rpm/find-requires emits lines with a leading # (more specitically a # on a line alone) and blank lines ... these kill the rpm packaging with the dreaded "Failed to find Requires:" error message The WAR is in out wrapper to cull this crap before the build fails. commit b231216e6e3dced71d73b9831868b1c4dc13e458 Author: Ken McDonell Date: Fri May 8 21:58:51 2015 +1000 build/rpm/pcp.spec.in: more conditional Requires: changes Remove a bunch of duplicated Requires: clauses. Move all the python ones so they are condtional on python being available in the build. Ditto for webapi. Fix the rm .Needrebuild error (add -f). commit 5a6515a2077589ec2d5798bcba9b3fe82590607c Author: Ken McDonell Date: Fri May 8 20:33:02 2015 +1000 qa/admin/check-vm: add platform specific sections Tracking the conditional Requires: in the rpm spec file, especially for the postfix pmda rpm. commit 2bf145af818f151e61d9f47c8e9d8b32f89ffe65 Author: Ken McDonell Date: Fri May 8 20:30:19 2015 +1000 pcp.spec.in: make Requires: platform specific Looking for qshape ... in different rpms on different distros. This does not fix the postfix pmda, that will require some other work, but it does resolve the build and install problem on SuSE. commit 9ccfdd8a677de5b27d010d7bfbfeff58d7509154 Author: Ken McDonell Date: Fri May 8 19:49:34 2015 +1000 qa/admin/check-vm: add rpm commit 7461af6e5f51d9c77a1a8c8ddaa127c32cb7a0fa Author: Lukas Berk Date: Thu May 7 18:49:33 2015 -0400 Wrap pcp-pmda-rpm and pcp-gui with proper %if checks pcp-pmda-rpm and pcp-gui aren't built on some platforms, wrapping them with proper checks so it doesn't fail on other platforms commit 0e4a8dc89363271e03cb3fa73ac7357a6a902a67 Author: Lukas Berk Date: Thu May 7 13:35:19 2015 -0400 Fix location of pcp-webjs gitweb in the pcp guide commit 011c53f5a5b575f689ea7eb50d4f4f61f669dc17 Author: Lukas Berk Date: Thu May 7 11:19:56 2015 -0400 spin-rawhide: Extract version info from VERSION.pcp At times (specifically after a release), the spec file can become out of sync with the VERSION.pcp. This tweak of spin-rawhide gets the specific version info from the definitive source (VERSION.pcp). commit af7310944455af885a42a6545f56d3d63eae7b9e Author: Ken McDonell Date: Thu May 7 17:34:11 2015 +1000 src/perl/PMDA/.gitignore: cvalue executable is not interesting commit 3884040a45e6a55e6fd8a4895847602fa391785c Author: Ken McDonell Date: Thu May 7 17:13:13 2015 +1000 qa/771: (new) exercise test.pl/cvalue.c from the perl PMDA bindings Need to reach across to the src directory to get the test.pl and cvalue.c bits (in the build), then execute the test in the (new) perl subdirectory. commit b1aaca27ffba17b49069e233c3d86fcc0ff618c8 Author: Ken McDonell

You can view, comment on, or merge this pull request online at:

Commit Summary

File Changes

Patch Links:

Vi invitiamo per un preventivo gratuito a
Hotel Michelangelo Milano
Piazza = Luigi di Savoia 6
20124 Milano - = Italia

Sabato il 23 = Maggio 2015 , = dalle ore 10 alle ore 17.
Basta portare una = ortopanoramica recente !

Primo viaggiogratis,
Prima = visita gratis,
Panoramica gratis = !

MODALITÀ = DI PAGAMENTO

Calcolatore prezzi

Siete interessati per sapere una spesa approssimativa dei trattamenti e = cure dentali?

Con il nostro calcolatore prezzi scoprite velocemente quanto dovreste = andare a spendere!

Visitate il nostro sito = web !

Clinico Dentale - Unlimited Smile
Strossmayerova 14, = 51000 Rijeka, Croazia
info@croazia-dentista.it

Vi invitiamo per un preventivo gratuito a
Hotel Michelangelo Milano
Piazza = Luigi di Savoia 6
20124 Milano - = Italia

Sabato il 23 = Maggio 2015 , = dalle ore 10 alle ore 17.
Basta portare una = ortopanoramica recente !

Primo viaggiogratis,
Prima = visita gratis,
Panoramica gratis = !

MODALIT=C0 DI = PAGAMENTO

Calcolatore prezzi

Siete interessati per sapere una spesa approssimativa dei trattamenti e = cure dentali?

Con il nostro calcolatore prezzi scoprite velocemente quanto dovreste = andare a spendere!

Visitate il nostro sito = web !

Clinico Dentale - Unlimited Smile
Strossmayerova 14, = 51000 Rijeka, Croazia
info@croazia-dentista.it

Bug ID	1109
Summary	fuzzy container hex-id naming leads to nondeterminism
Product	pcp
Version	unspecified
Hardware	All
OS	Linux
Status	NEW
Severity	major
Priority	P5
Component	pcp
Assignee	pcp@oss.sgi.com
Reporter	fche@redhat.com
CC	pcp@oss.sgi.com
Classification	Unclassified

Bug ID	1110
Summary	excessive workload in pmdaroot for --container clients
Product	pcp
Version	unspecified
Hardware	All
OS	Linux
Status	NEW
Severity	major
Priority	P5
Component	pcp
Assignee	pcp@oss.sgi.com
Reporter	fche@redhat.com
CC	pcp@oss.sgi.com
Classification	Unclassified

Bug ID	1111
Summary	--container=NO_SUCH_CONTAINER succeeds
Product	pcp
Version	unspecified
Hardware	All
OS	Linux
Status	NEW
Severity	major
Priority	P5
Component	pcp
Assignee	pcp@kenj.com.au
Reporter	fche@redhat.com
CC	pcp@oss.sgi.com
Classification	Unclassified

=
Calcolatore prezzi Siete interessati per sapere una spesa approssimativa dei trattamenti e = cure dentali? Con il nostro calcolatore prezzi scoprite velocemente quanto dovreste = andare a spendere! Visitate il nostro sito = web !

You can view, comment on, or merge this pull request online at:

Commit Summary

File Changes

Patch Links:

Vi invitiamo per un preventivo gratuito aHotel Michelangelo MilanoPiazza = Luigi di Savoia 620124 Milano - = Italia

Sabato il 23 = Maggio 2015 , = dalle ore 10 alle ore 17.Basta portare una = ortopanoramica recente !

Primo viaggiogratis, Prima = visita gratis, Panoramica gratis = !

MODALITÀ = DI PAGAMENTO

Calcolatore prezzi

Siete interessati per sapere una spesa approssimativa dei trattamenti e = cure dentali?

Con il nostro calcolatore prezzi scoprite velocemente quanto dovreste = andare a spendere!

Visitate il nostro sito = web !

Clinico Dentale - Unlimited SmileStrossmayerova 14, = 51000 Rijeka, Croaziainfo@croazia-dentista.it

Vi invitiamo per un preventivo gratuito aHotel Michelangelo MilanoPiazza = Luigi di Savoia 620124 Milano - = Italia

Sabato il 23 = Maggio 2015 , = dalle ore 10 alle ore 17.Basta portare una = ortopanoramica recente !

Primo viaggiogratis, Prima = visita gratis, Panoramica gratis = !

MODALIT=C0 DI = PAGAMENTO

Calcolatore prezzi

Siete interessati per sapere una spesa approssimativa dei trattamenti e = cure dentali?

Con il nostro calcolatore prezzi scoprite velocemente quanto dovreste = andare a spendere!

Visitate il nostro sito = web !

Clinico Dentale - Unlimited SmileStrossmayerova 14, = 51000 Rijeka, Croaziainfo@croazia-dentista.it

Vi invitiamo per un preventivo gratuito a
Hotel Michelangelo Milano
Piazza = Luigi di Savoia 6
20124 Milano - = Italia

Sabato il 23 = Maggio 2015 , = dalle ore 10 alle ore 17.
Basta portare una = ortopanoramica recente !

Primo viaggiogratis,
Prima = visita gratis,
Panoramica gratis = !

Clinico Dentale - Unlimited Smile
Strossmayerova 14, = 51000 Rijeka, Croazia
info@croazia-dentista.it

Vi invitiamo per un preventivo gratuito a
Hotel Michelangelo Milano
Piazza = Luigi di Savoia 6
20124 Milano - = Italia

Sabato il 23 = Maggio 2015 , = dalle ore 10 alle ore 17.
Basta portare una = ortopanoramica recente !

Primo viaggiogratis,
Prima = visita gratis,
Panoramica gratis = !

Clinico Dentale - Unlimited Smile
Strossmayerova 14, = 51000 Rijeka, Croazia
info@croazia-dentista.it