On 01/16/2013 12:43 PM, Bill Peck wrote:
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?
Yes, it is autoyast. It's based on XML, very much like the windows
unattended install files.