pcp
[Top] [All Lists]

Re: [pcp] QA Status

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] QA Status
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Wed, 16 Mar 2016 15:30:13 +1100
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1802774654.30943571.1458082920173.JavaMail.zimbra@xxxxxxxxxx>
References: <56E7D66F.9010601@xxxxxxxxxxxxxxxx> <1802774654.30943571.1458082920173.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
On 16/03/16 10:02, Nathan Scott wrote:
> Hi Ken,
> ...
 
> Still keen on host access there for qa/878, but ultimately think we'll just
> end up having to open up some timing windows/deltas beyond the current used
> settings in the test.

I've spoken to the firewall orgre (that would be me, a la Brenda from 
Bankworld) and you should have access to vm03 now.

>>     1038     5  3 1 1
>>      666     4  1 1 1 1
>>     1069     3  3
>>     1062     3  3
>>      880     3  3
>>      823     3  1 1 1
> 
> I've pushed in fixes for a couple, but I'm a bit mystified that some of the
> OrderedDict _notrun checks seem to pass but then pmrep fails to find it?  I
> have checked pmpython, and pmrep, and the QA tests all *seem* to be getting
> the same python ... so not sure how that can be.

The mystery is that my QA cycle is 2-3 days for all machines, may be twice that 
if something goes wrong and a whole run is lost on one VM ... I checked vm11 
after git pull and all of these pass there now, so these should naturally 
decline over the next day or so.

> Perhaps the python versions on these failing hosts are not setting the exit
> code to non-zero once they fail to import OrderedDict in the _notrun check?

If they call _notrun, the exit status is not negotiable ... we don't return 
from _notrun.

>>      756     3  3
> 
> This last one is a complete mystery - has the qa/perfevent/perfevent_test
> binary not been installed / updated for awhile on these hosts perhaps?  It
> is failing to run several new tests that were added there (C code) for the
> (new this release) pmdaperfevent server-side derivation metrics - there is
> an unconditional printf that should be visible in each of those cases, but
> its nowhere to be seen in the output...

This is a makefile engineering issue.

0. I run QA out of the git tree, everyone else seems to use the testsuite 
package installed directory
1. this is not going to change
2. the build no longer descends into qa in the git tree ... the build happens 
in some pcp-x.y.z tree
3. QA has a preference for using the GNUmakefile.install over GNUmakefile when 
check runs "make setup"
4. in the qa/perfevent subdir, GNUmakefile.install does next to nothing

So on one of my failing systems ...

This happens ...

kenj@bozo:~/src/pcp/qa/perfevent$ make -n -f GNUmakefile.install setup
tar xf fakefs.tar.gz

And this is what needs to happen ...

kenj@bozo:~/src/pcp/qa/perfevent$ make -n -f GNUmakefile setup
mkdir -p target
gcc -Wall -O0 -ggdb -I../../src/pmdas/perfevent -D_GNU_SOURCE 
-DFILESYSTEM_ROOT='"./fakefs/"' -c -o target/perf_event_test.o 
perf_event_test.c 
flex -P yyest -o configparser.yytest.c ../../src/pmdas/perfevent/configparser.l
mkdir -p target
gcc -Wall -O0 -ggdb -I../../src/pmdas/perfevent -D_GNU_SOURCE 
-DFILESYSTEM_ROOT='"./fakefs/"' -c -o target/configparser.yytest.o 
configparser.yytest.c 
mkdir -p target
gcc -Wall -O0 -ggdb -I../../src/pmdas/perfevent -D_GNU_SOURCE 
-DFILESYSTEM_ROOT='"./fakefs/"' -c -o target/perfinterface.o 
../../src/pmdas/perfevent/perfinterface.c 
gcc -Wall -O0 -ggdb -Wl,--wrap,syscall -Wl,--wrap,ioctl -Wl,--wrap,read 
-Wl,--wrap,close -Wl,--wrap,malloc -Wl,--wrap,sysconf -o perfevent_test 
target/perf_event_test.o target/architecture.o target/mock_pfm.o 
target/rapl-interface.o target/configparser.yytest.o target/perfinterface.o -lm
mkdir -p target/gcov
gcc -Wall -O0 -ggdb --coverage -I../../src/pmdas/perfevent -D_GNU_SOURCE 
-DFILESYSTEM_ROOT='"./fakefs/"' -c -o target/gcov/perf_event_test.o 
perf_event_test.c
mkdir -p target/gcov
gcc -Wall -O0 -ggdb --coverage -I../../src/pmdas/perfevent -D_GNU_SOURCE 
-DFILESYSTEM_ROOT='"./fakefs/"' -c -o target/gcov/configparser.yytest.o 
configparser.yytest.c
mkdir -p target/gcov
gcc -Wall -O0 -ggdb --coverage -I../../src/pmdas/perfevent -D_GNU_SOURCE 
-DFILESYSTEM_ROOT='"./fakefs/"' -c -o target/gcov/perfinterface.o 
../../src/pmdas/perfevent/perfinterface.c
gcc -Wall -O0 -ggdb --coverage -Wl,--wrap,syscall -Wl,--wrap,ioctl 
-Wl,--wrap,read -Wl,--wrap,close -Wl,--wrap,malloc -Wl,--wrap,sysconf -o 
perfevent_coverage target/gcov/perf_event_test.o target/gcov/architecture.o 
target/gcov/mock_pfm.o target/gcov/rapl-interface.o 
target/gcov/configparser.yytest.o target/gcov/perfinterface.o -lm
rm configparser.yytest.c

This whole area is a minefield, and what seems like a perfectly sane approach 
for one of the qa subdirs blows up for another ... let me think about this for 
a bit before deciding the best course of action.

Pro tem, this is a QA failure, not a code failure.

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