On 01/16/2013 12:21 PM, Lucas Meneghel Rodrigues wrote:
On 01/15/2013 11:31 PM, Dan Callaghan wrote:
> Excerpts from Nick Coghlan's message of 2013-01-16 11:11:05 +1000:
>> - Retained explicit mention of Beah (now as a separate trailing
>> paragraph), as I want to start down the path to supporting other test
>> execution frameworks like STAF and autotest (as mentioned in Dan's
>> email last year about defining a harness API). Actually making that
>> happen is going to require that we draw a sharper distinction between
>> Beaker-the-lab-management-tool and
>> Beah-the-task-execution-environment, and the blurb is an easy place to
>> start that process.
Not sure if I should start another thread about that, but what about
using autotest as an alternative harness to beah? I didn't follow the
discussion about defining a harness API (I'll read it during the
morning), but what I can remember is, we had some prototype
implementations, and people sent me patches, which I applied to autotest
to make both systems interact better.
I haven't heard much news after that. Is there anything we could do to
help to get the autotest client to play nice with beaker, so it can be
used as a harness?
STAF and autotest are the two alternate harnesses on my personal wishlist.
I know some folks currently get autotest running by provisioning the
host system via beaker, then firing up autotest in a VM. Essentially,
they use Beaker as an IaaS to get a KVM capable system, then do their
own provisioning for the guest VM.
It's rather clumsy, and also means that Beaker has basically zero
visibility into the results of the task in that case - hence the idea in
the thread last month about letting an alternate harness pass a URL up
to Beaker saying "the real test results are over there".
Another subject that I find interesting is how we could make beaker
more
useful for distros that are not based on rpm. In autotest we have some
strategies that make it run in more distros, such as debian based, and
we could figure out some solution for beaker.
The main challenge there is that Beaker's current provisioning and
configuration system is coupled really tightly with anaconda kickstarts.
So, rather than trying to make Beaker into a full IaaS solution, it
seems to make sense to instead look at VM image based provisioning in
*other* IaaS solutions.
We started down this path with the oVirt Engine integration in 0.10 -
while the dynamic VM provisioning currently installs the OS from scratch
the same way we do in the rest of Beaker, the potential is at least
there to also support image-based provisioning.
I actually see the two topics as quite closely related - testing on
other distros (or even operating systems) really means supporting VM
image based provisioning, but Beah/RHTS also depend on the kickstart
files for their configuration, so image based provisioning itself
arguably depends on being able to use alternate test harnesses.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (
http://beaker-project.org/)
GlobalSync Development Lead (
http://pulpdist.readthedocs.org)