On 01/15/2013 07:02 PM, Dan Callaghan wrote:
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 
    test computers.

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 
action shot.

With Beaker, users and administrators are able to:
s/are able to/can/

- Manage systems across multiple, potentially globally distributed, labs
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 
point?

- Maintain an automated inventory of system hardware details
s/system hardware/hardware/

- Provision execution environments on systems
What does "execution environment" even mean? Let's stick with "operating 
system".

- 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 
like:

Suse won't work unless we add the equivalent of kickstart.  I think its autoYast?

    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>`__ community project.
================================

(Note: rather than that last line, it may be better to incorporate the 
"A Red Hat community project" image visible at 
http://www.pulpproject.org/ into the site layout)
+1 to this, I wonder if we need to check with someone for permission to 
use the logo thing.



_______________________________________________
Beaker-devel mailing list
Beaker-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel