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).
================================
With Beaker, users and administrators can:
- Manage systems across multiple labs
- Maintain an automated inventory of system hardware details
- Provision task execution environments on systems
- Schedule tasks to run on one or more systems
- Store and view task results
By focusing on different aspects of the service, Beaker can be used as a:
- test automation framework
- searchable machine inventory
- system provisioning engine
- task scheduler
- hardware lab management tool.
Beaker currently supports Anaconda and RPM-based Linux distributions,
including Fedora and Red Hat Enterprise Linux. It supports a wide
variety of
hardware platforms, and can integrate with oVirt Engine for
dynamic VM provisioning.
Sounds good, I like this para now.
Tasks are defined using the Beah task execution framework, a
component
of Beaker.
Same as above, this is not really true... beah is not involved at all in
defining tasks, beah just happens to be the thing we use to run
RHTS-formatted tasks.
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.