Excerpts from Nick Coghlan's message of 2013-01-15 12:56:40 +1000:
I liked all Ray's suggestions, so here's an updated draft,
with a few
additional changes to help make the result flow better. Notably, I
couldn't figure out how to keep the old second paragraph given the
expanded bullet list of use cases:
Beaker provides distributed provisioning and management for test
infrastructure shared by multiple development and quality assurance teams.
I think it's important to have one good, concise, punchy sentence at the
very top to quickly explain what Beaker is for the drive-by visitors.
This one feels like it tries to cram too much information in, and that
makes it difficult to parse. Also we already have a lede above the
"action shot", and it's:
Beaker is open-source software for managing and automating labs of
which I think is better because it's simpler and easier to parse (but
I'm biased because I wrote it). Either way, I think we don't need this
first para in the blurb, it should be the lede in large type above the
With Beaker, users and administrators are able to:
s/are able to/can/
- Manage systems across multiple, potentially globally distributed,
I feel like this "potentially globally distributed" is even more awkward
now. :-) Can we just ditch it altogether? Is it that big of a selling
- Maintain an automated inventory of system hardware details
- Provision execution environments on systems
What does "execution environment" even mean? Let's stick with
- 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 is currently based on:
- Anaconda kickstarts for bare metal system provisioning
- KVM/virsh for guest system provisioning
- oVirt for dynamic virtual system provisioning
- RPM for task definition and distribution
- the Beah framework for task execution
I'm not too keen on having three chunky bullet lists making up our
introductory material. I think this one could be cut down, especially
since some of those things are essentially an implementation detail.
Beah in particular doesn't deserve a mention since it is just an
off-shoot of Beaker.
If we're being honest about our limitations then we could go one step
further and explicitly say that Beaker is only useful for RHEL and
Fedora (at present). Or maybe "RPM-based distros" is better, since
CentOS works, and I have a feeling SUSE might too. How about something
Beaker currently supports RPM-based Linux distributions, including
Fedora and Red Hat Enterprise Linux. It supports a wide variety of
bare-metal hardware[?], and can integrate with oVirt Engine for
dynamic VM provisioning.
Beaker is a `Red Hat <http://www.redhat.com>`__
(Note: rather than that last line, it may be better to incorporate the
"A Red Hat community project" image visible at
into the site layout)
+1 to this, I wonder if we need to check with someone for permission to
use the logo thing.
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.