Excerpts from Nick Coghlan's message of 2013-01-16 11:48:31 +1000:
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?
Well the commands are all named rhts-*, so maybe :-)
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.
This is backwards. By "RHTS compatibility layer" I assume you mean the
code in the rhts package.. that isn't a compatibility layer, it is the
actual original test environment bits from RHTS, mostly unchanged. Beah
is the one with the compatibility layers to emulate an RHTS scheduler on
localhost, and all the other stuff.
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.
Right so this is purely a naming debate. But I think the name should not
be "Beah execution environment" but rather "RHTS-compatible execution
environment" or "execution environment for RHTS-format(ted) tasks" or
something like that. Reasons:
- All the commands are called rhts-*
- Beah doesn't define anything itself, it just emulates RHTS
- RHTS predates Beaker and Beah
I see beah's existence as purely an implementation detail of supporting
RHTS-formatted tasks (or an "RHTS-compatible execution environment") in
Beaker. Some theoretical alternative/future harness might also support
RHTS-formatted tasks, without having anything in common with Beah.
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.