On 2016-01-29 01:59, Nathan Scott wrote:
> ----- Original Message -----
>>
>> I've now gotten a QA test case (1069) running with the following steps
>> on my local system without sudo or pcpqa user or other such tricks:
>>
>> 0) Prepare local PMCD but installing sample and simple PMDAs and adding
>> -T 3 to pmcd.options
>
> Hmm, so this step 0 requires a local install and local root access. Which
> tests will sometimes use and other times not, I think, reading through the
> rest here...
The situation is a bit same if I'm writing a patch and testing something
for glibc, I (obviously :) have system glibc installed and in use but
tests are done with development tree / installation.
>> 1) Configure and install PCP from pcp.git under /tmp/pcp, then operate
>> under the installation location /tmp/pcp, not in the source tree
>>
>> 2) Replace /usr/bin/pcp (!) with the version from pcp.git as the test(s)
>> seem to want to use /usr/bin/pcp no matter what and the version I had
>> was buggy (missed ff3e6bc)
>>
>> 3) Set env variables - the trick here is to use PCP_DIR as PCP_CONF does
>> not work for some reason (this explained the issues compiling
>> clienttimeout.c etc I mentioned earlier):
>>
>> export PATH=/tmp/pcp/bin:$PATH
>> export LD_LIBRARY_PATH=/tmp/pcp/lib
>> export PCP_DIR=/tmp/pcp
>> export PYTHONPATH=/tmp/pcp/lib64/python3.3/site-packages/
>>
>> 4) Fix some issues after make install / with incomplete Makefile:
>>
>> mkdir -p /tmp/pcp/var/tmp /tmp/pcp/var/lib/pcp/pmns
>> cp $SRCDIR/pcp.build/src/pmns/* /tmp/pcp/var/lib/pcp/pmns/
>
> Eek, I'd definitely have walked away at that point. :)
Perhaps those are usually done by packages? Or the latter might be also
a Makefile issue, not sure.
>> 5) Add an "exit 0" at the top of test 994 as the check will complain
>> about file owners needlessly and gets run even though we're running an
>> unrelated test
>
> Ugh. Removing this verification check globally isn't good for the more
> common case of people doing fully-installed-system verification.
Yeah, removing it unconditionally would not be a good idea, perhaps if
the user is not pcpqa and no sudo is available, then skip it (with a
warning).
>> 6) Check the set (no idea why this takes longer than configure + make +
>> make install combined earlier):
>
> FWIW, this will be creating the QA archives (pmlogger) - takes awhile.
Ah, ok.
>> 7) Finally execute the test:
>>
>> ./check 1069
>>
>> So it seems we're very near a stage where individual tests which do not
>> require any special setup can now be run locally without sudo or pcpqa.
>
> Wow, thats a lot of hoops to jump through. I guess I'll still recommend
> the more real-life-testing option of using a QA VM with actual installed
> packages (as a user would see 'em), if local install is not feasible. I
> suspect there will always be fragility to the above type of approach, and
> it limits testing to just a handful of tests (not something we want to be
> encouraging).
>
> OTOH, I agree it'd be good to have an in-between level for people writing
> their first tests, where life is made alot less difficult ... somehow.
> Maybe the Vagrant setup Ryan & Martins did awhile ago is worth revisiting
> to help make things easier here?
OTOH, for a known individual test case Vagrant would again be an extra
step. But since I'm now able to work with pmrep tests without any
VM/Vagrant setup so I can now live with the current situation but if I
were to test something similar in the future, VM setup would again be an
extra step which might lead me to do something else instead.
Thanks,
--
Marko Myllynen
|