5:43 a.m.
Hello!
This is (another) one of my endless proposal emails, sorry about that :).
We discussed a way of enabling users to define their own tests and tools
without the necessity to add modules to site-packages/ on the controller
and all the slaves by hand.
This should be done by creating a directory at the controller machine
that will contain the tests. The controller machine will send them to
the slave through a xml-rpc method and the slave will be able to use
them.
I dug into this a little more today and I had some ideas that I'd like
to present here.
There are two things we deal with nowadays. Python test modules that
represent Test* commands directly and test tools that can be in an
arbitrary format. The tools are later used by the modules, to perform
test tasks.
I personally think, that this model is great. It allows you to set up
everything you need at the controller, e.g, prepare the test tools,
write a new command, that will allow using them with LNST, write the
recipe and then one-click execute them in your lab. You don't have
to ssh to 5 (or even more) different machines to install the tools.
That's the most tedious thing about networking tests. Manually preparing
all the machines for the tests. I think the key feature of LNST
facility is making the test setup and execution as easy and as much
automated as possible.
Currently, the test modules (Test/Test*.py) are an integral part of
the LNST package. They are available to controller machines as well as
to slave machines. The inconsistency here is, that controller doesn't
need to execute them. It only wants to take them and send them over
to the slaves. I think that we could take them out from LNST core
and treat them a little differently.
There are two categories of tests:
* upstream - currently lnst/Tests/Test*.py
* user-defined - configurable; defaults to ~/.lnst/Tests
We could put all the upstream tests to /usr/share/lnst instead of
having them within the tree directly. The test execution would then
work like this:
1. Controller starts the test
2. It will contact the slave and send him hashes of all the
Test*.py commands that will be necessary to execute the recipe
3. Slave will look within his tests cache located in /var/cache/lnst
to see if it does have the tests already
4. If not, controller will transfer all the files to the slave
5. The test can begin :-)
The key feature is, that the slave would not search any directories
other than his test cache, which would after a few executed recipes
get almost 100% hit-rate. The great thing about the hashes is, that
in case the test is changed in any way at the controller, it will
be transfered again to the slave.
Consequentially to this, we could pack LNST into two (maybe three
due to some common code) different packages:
* lnst-controller
* lnst-slave
* (lnst-common)
What do you think?
-Radek