LNST + Beaker

[Radek Pazdera]

Hi :-)!

Now, that the libvirt integration patch for LNST has been applied, it's
probabbly time to start talking about the integration with beaker.

We discussed it a long time ago at the first meeting about the libvirt
integration and I think that it's a great idea!

The workflow could look something like the following:

 1) Create, test and debug a recipe using your own virtual environment
 2) Someone else would like to run the test as well, but he doesn't want
    to install anything manually
 3) => Add it to beaker!

I looked at the support of virtual guests in beaker and it seems usable.
You need to specify a <guestrecipe> tag for each virtual guest that you
want to have on your beaker machine.

I thought a little about the scheme already and it would be nice
to have something like this:

  * PACKAGE: rpm package 'lnst.noarch' available from public rhel/fedora
             or some internal QE repo? This would solve the dependency
             issues on specific versions of python, since it could be a
             requirement for the package to install.
         
             (I could do this, I always wanted to learn to pack rpms :))

  * TASK 1: Slave task, that would sipmply just executed the slave and
            wait for something to happen.

  * TASK 2: Controller task, this would be equaly simplistic as the
            slave task. It would simply run nettestctl.py with a
            recipe path passed as a parameter to the task.

  * TASK 3: Recipe install task, again a very simple task, that would
            carry a recipe XML with a specific test recipe. This task
            would only install a recipe to some well-known location
            so the controller can find it and execute it.

So the complete execution of a LNST test recipe in beaker would look
like this:

 1) Reserve & install bare-metal controller
    - also install lnst package on the controller (probably just
      using <packages> tag)

 2) Create & install virtual slaves
    - also install lnst package on slaves (again using <package> tag)

 3) Execute LNST_SLAVE task on slaves
    - this will be done in the <guestrecipe>

 4) Execute LNST_RECIPE_INSTALL_<recipe_name> task on controller
    - this will get the recipe to be executed
    - can be repeated multiple times

 5) Execute LNST_CONTROLLER task on the controller
    - to run all the installed recipes

 6) Finish test, check the results :)


One disadvantage of this approach is, that the tester has to create
the whole beaker recipe so it matches the lnst recipe's requirements
on each test run. It would be nice to automate this step as well
(the information is already stored within the LNST recipe).

Maybe it would be possible to bypass/hack the provisioning somehow, so
the information about how many machines are needed is taken directly
from the LNST recipe. But I haven't looked into that yet.

What do you think? Do you have any ideas?

Cheers,

Radek :)