[Maas-devel] Testing SRU/trunk packages in the QA Lab

Raphaël Badin raphael.badin at canonical.com
Sat Nov 17 13:16:36 UTC 2012


Hi all,

I've been working in the QALab to test the SRU packages last week, here 
are the results.

= Executive summary =

The quantal SRU package and the package built from trunk are fine (all 
the integration tests pass).

The precise SRU package still has a couple of bugs but I was able to get 
all the integration tests to pass using workarounds which means that all 
the problems have been identified.

= Integration tests =

Diogo and I have improved the integration tests last week, we now test 
all the way up to a real-world juju deployment of mediawiki (we choose 
mediawiki over wordpress because the wordpress charm downloads stuff 
from github when it installs and the QALab is very restrictive in terms 
of external web access).

= Quantal SRU =

Using python-tx-tftp 0.1~bzr31-0ubuntu7~ppa1 and maas 
0.1+bzr1304+dfsg-0ubuntu2~ppa1 (a package I've built in my ppa 
https://launchpad.net/~rvb/+archive/maas.quantal): all the integration 
tests pass.

= Trunk package =

Same result (success) for the "trunk package" (i.e. the one in the daily 
ppa).

= Precise SRU =

Using the package created by Julian in the experimental ppa 
(0.1+bzr1297+dfsg-0ubuntu1~12.04.2~ppa2), I found a a couple of 
problems, only one (#2) is new:

1. The dhcp server cannot access its config due to apparmor restrictions
This has already been reported by Julian: 
https://bugs.launchpad.net/maas/12.04-nocobbler/+bug/1079030

Workaround: disable apparmor (sudo /etc/init.d/apparmor teardown)

2. Bug in our backport of the Django 1.4 method prefetch_related
The error: http://paste.ubuntu.com/1362899/
This can be exercised by running the test suite on a precise instance, 
install 1.3.1-4ubuntu1.4~precise1+ppa1 (with includes the backport of 
prefetch_related) and run the test suite of the 1.2 branch.
I /think/ this is because we need the feature introduced in 
https://code.djangoproject.com/ticket/17003
  for prefetch_related to work.  This will need more investigation to be 
fixed properly.

Workaround: comment out the calls to prefetch_related in the MAAS code 
(these calls are just optimisations).

3. We need to use the juju package from the PPA ppa:juju/pkgs instead of 
the one in precise, otherwise we get that error 
http://paste.ubuntu.com/1362994/.
I seem to remember that there is a known bug in precise juju which 
forces us to include a port somewhere in the config file but I cannot 
seem to find that bug, please point it out to me if you have the link.

Workaround: install juju from the ppa ppa:juju/pkgs.

So I used all the workarounds described above and I got all the 
integration tests to pass, which means that the finish line is in sight :).

See it for yourself: http://paste.ubuntu.com/1364846/

- In the output of 'juju status' (link above), the fact that the nodes 
are named node-00e081ddd599.local in one part and 
node-00e081ddd599.master in another part is due to bug 1078744 which is 
already fixed in the 1.2 branch.

- In the output of 'juju status' (link above), the fact that the nodes 
are named using mac-based names (instead of using 5-letter generated 
hostnames) is also something that is fixed in the 1.2 branch.

The next precise package to be created will be free of these bugs.

Cheers,

R.




More information about the Maas-devel mailing list