Parallel static python checks with Makefiles

To make testing fun I looked at improving the speed of static syntax checks.
The latest incarnation is now using make targets to represent a specific checks. The nice thing about this is, that you can use Make's -j switch to run those tests in parallel.

So basically it looks like this:

check-static-pep8: $(PYTHONSOURCES:%=%.pep8)
 @echo Passed $@

%.pep8:
 PYTHONPATH=. pep8 -r "$*"

The complete makefile is here and the numbers:

Simple:

...
---
 Passed check-local
---

real 0m22.875s
user 0m20.466s
sys 0m2.158s

And in parallel:

---
 Passed check-local
---

real 0m11.459s
user 0m34.780s
sys 0m3.325s

There is so much that can be done.

Igor - Testing an OS on real and virtual hardware

Working on oVirt Node is nice, this minimal, firmware like, rock-solid, (non-official) Fedora "spin", is oVirts "hypervisor".

One challenge is to keep Node rock-solid.
Typically you can add unit tests to your software to shield yourself from regressions (or at least discover them early) but adding tests to Node wasn't that easy as Node is a complete "operating system" and not just one component. It is currently composed of approximately 450 packages - all of these change independetly.

We were looking for a way to automate some basic tests on development or released images. But a requirement to run the tests is a running Node. This means testing requires an installation (and subsequent a removal or "freeing" of th eused host) on different hardware, including virtual machines.
So we needed a tool that could control the whole life-cycle (provision, run tests, and freeing) of a machine (either real or virtual) and which is also monitoring the progress of a testsuite, to act accordingly (e.g. killing it if it times out).
We did not find such a tool and came up with igor.

Igor expects a working PXE environment (so a lan with some DHCP and PXE server like Cobbler) and some hosts or a libvirtd instance. It is expected that all hosts (real and virtual) boot via PXE from the PXE server.

In such an environemtn Igor can control the PXE server to modify the configuration for existing hosts (or add configuration for short-living hosts like a VM) to install an oVirt Node image.
After changing the PXE configuration and booting up the host Igor steps back and either waits for a controlled ending of the testsuite (signaled via a RESTlike API) or a timeout. When it receives such a signal it shuts down the host and restores the original PXE configuration.

So that's a first build-block of how we automated the testing of oVirt Node. I haven't gone into detail how the testcases look like and how we are actually testing our TUI. Also I didn't mention the client which is running on (an edited) oVirt Node image tu actually run the tests.

Igor can be found here and is intended to be used on a developers machine (or in conjuction with jenkins).

p.s.: It is getting interesting when Igor is paired with a client using python-uinput to inject mouse and keyboard events.