On 01/16/2013 11:31 AM, 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.
I think this is a false distinction, or not the right distinction
anyway... Beah does not define the task execution environment, RHTS
does. Beah just provides an RHTS-compatible environment (by literally
emulating RHTS).
From the perspective of someone using Beaker though, do they really
care that the API published by Beah was originally defined by RHTS?
Essentially, we need a name for "the parts of Beaker that run on the
system under test", as opposed to the parts that run on the main server
and the lab controllers. I'm proposing we use "Beah" as that name, even
if the term has historically been used in a narrower sense. After all,
the RHTS compatibility layer and the beakerlib project rely on Beah to
actually talk to the Beaker infrastructure.
All the stuff in the beah and rhts repos, as well as the stuff we set up
server side through the kickstart templates, could then be described as
the "Beah execution environment", opening the door for us to have
*other* execution environments on the systems under test in the future.
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)