Great news! Thanks for the efforts!
> * What hardware will be added?
For the starter of the kernel testing, we definitely need some bare-metal systems for all archs that Fedora supports, and VT systems that we can perform virt-related testing.
> * What tests to deploy?
We would like to move more kernel tests to Fedora as much as possible. Most are general purpose kernel testing without too much enterprise hardware dependency. For example,
* KernelTier1 and KernelTier2 tests.
* kdump tests.
* perhaps hardware cert v7 tests.
> * Who will run and review the tests?
We'll have someone dedicated to look after kernel testing in Fedora, so he/she will run and review those tests.
Just fleshing out some ideas on how Beaker may work with Fedora.
Remember this is not a replacement for autoQA, Beaker is about finding
the hardware described in the test plan, provisioning the distro under
test, adding any additional packages, and finally running the tests.
The final part is done by the harness which could be beah (Beaker
Harness) or autotest.
Looking at the road map below there are more questions then answers.
But we have to start somewhere. :-)
Fedora Beaker test road Map
* Package Review (waiting on reviewer)
* Proof of concept Deployment (to be done by bpeck after package review)
* Meet with Fedora Infrastructure on how to deploy in Fedora space.
* Who will admin the software of the Fedora instance (bpeck most likely)
* What hardware will be added?
* What tests to deploy?
* Who will run and review the tests?
Scheduler is now merged into master. I'm in the middle of renaming
python/site-packages/beaker to python/site-packages/bkr. Why you ask?
because there is another beaker packaged called python-beaker which is
using that path. So it sucks and its painful but we have no choice but
I'm testing it local before I push up.
While testing the harness I ran across the following:
- I passed in an invalid repo and it of course kept the harness from
being able to install the tasks. The harness aborted the current task
and seemed to have stopped. Aborting seems like a sensible thing to do
here but I think you should abort the whole recipe and not just the
task. Otherwise we end up waiting for the watchdog to kick in anyway.
I'm going to merge the Scheduler branch back into master later Today. I
did a test merge on a copy of the repo and it went smoothly. Before I
do the real merge I'll be making a branch of current master for bug
fixes. That branch will be called beaker-0_4
Once that happens I'd like all bug fixes to be made in a branch off of
that and I'll be the gatekeeper to merge them into master and beaker-0_4
if it applies there.