Hi Marko,
----- Original Message -----
> Hi,
>
> 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...
> 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. :)
> 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.
> 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.
> 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?
cheers.
--
Nathan
|