It has been pointed out [1] that the current home page blurb doesn't do a great job of describing Beaker's purpose and capabilities. While I think Ed's suggested wording is an improvement over the status quo, I have a few additional proposed changes of my own. Rather than trying to work out the details in patch comments, I figure it makes more sense to get rough consensus on new wording here, then we can update the home page and any affected project descriptions in the documentation accordingly.
Here's my current draft
================================ Beaker is a tool to provide and manage globally distributed testing infrastructure shared by multiple development and quality assurance teams.
With Beaker, users and administrators are able to: - Manage systems in a globally distributed network - Maintain an automated inventory of system hardware details - Provision execution environments on systems - Schedule tasks to run on one or more systems - Store and view task results
Beaker enables users to create any task they would like (from testing changes to kernel memory management to installing their favourite OS and game server) and run these tasks on any number of machines of any specification located anywhere in the world, and provides a central interface where the outcome of these tasks can be reviewed.
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
Developed by `Red Hat http://www.redhat.com`__, Beaker can be used as a searchable machine inventory, system provisioning engine, task scheduler, test automation framework and hardware lab management tool.
================================
Once we have a more accurate description of the status quo, then I believe it becomes easier to create a description of "things we're interested in doing differently" (such as supporting execution frameworks other than Beah, task distribution with Git, image based provising of guest and dynamic virt systems, etc).
Regards, Nick.
[1] http://gerrit.beaker-project.org/#/c/1257
----- Original Message -----
From: "Nick Coghlan" ncoghlan@redhat.com To: beaker-devel@lists.fedorahosted.org Sent: Tuesday, January 15, 2013 11:49:01 AM Subject: [Beaker-devel] Updating the home page blurb for Beaker
It has been pointed out [1] that the current home page blurb doesn't do a great job of describing Beaker's purpose and capabilities. While I think Ed's suggested wording is an improvement over the status quo, I have a few additional proposed changes of my own. Rather than trying to work out the details in patch comments, I figure it makes more sense to get rough consensus on new wording here, then we can update the home page and any affected project descriptions in the documentation accordingly.
I'll do my best at nit picking.
Here's my current draft
================================ Beaker is a tool to provide and manage globally distributed testing infrastructure shared by multiple development and quality assurance teams.
I don't think there is a need to restrict beaker to a global environment.
I imagine its supposed to make beaker sound more impressive, yet borders and trans-oceanic voyages are not written into Beaker and so perhaps don't help when people evaluate beaker for their purposes. I think the description further below about "anywhere in the world" outlines the extent of the distributility(?) or Beaker's inventory.
I would say s/globally distributed/distributed/.
With Beaker, users and administrators are able to:
- Manage systems in a globally distributed network
Again with the globally.
- Maintain an automated inventory of system hardware details
- Provision execution environments on systems
- Schedule tasks to run on one or more systems
- Store and view task results
Beaker enables users to create any task they would like (from testing changes to kernel memory management to installing their favourite OS and game server) and run these tasks on any number of machines of any specification located anywhere in the world, and provides a central interface where the outcome of these tasks can be reviewed.
Do we need to make clear that all this variety actually needs to be provided by someone, and that people who download and install beaker are not plugging into an existing network or resources?
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
Developed by `Red Hat http://www.redhat.com`__, Beaker can be used as a searchable machine inventory, system provisioning engine, task scheduler, test automation framework and hardware lab management tool.
This looks a bit like SEO spam (although I'm no SEO expert). Should we have it as a bullet list as we do the two previous paragraphs? Also Would it make more sense to put this at the top, that way from top to bottom we are going from higher overview and use cases, down to implementation details. This may grab people quicker if they see things like 'test automation framework' etc.
================================
Once we have a more accurate description of the status quo, then I believe it becomes easier to create a description of "things we're interested in doing differently" (such as supporting execution frameworks other than Beah, task distribution with Git, image based provising of guest and dynamic virt systems, etc).
Regards, Nick.
[1] http://gerrit.beaker-project.org/#/c/1257
-- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead Beaker Development Lead (http://beaker-project.org/) GlobalSync Development Lead (http://pulpdist.readthedocs.org) _______________________________________________ Beaker-devel mailing list Beaker-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
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.
With Beaker, users and administrators are able to: - Manage systems across multiple, potentially globally distributed, labs - Maintain an automated inventory of system hardware details - Provision 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 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
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)
Cheers, Nick.
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:
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.
----- Original Message -----
From: "Dan Callaghan" dcallagh@redhat.com To: "Nick Coghlan" ncoghlan@redhat.com Cc: "beaker-devel" beaker-devel@lists.fedorahosted.org Sent: Wednesday, January 16, 2013 10:02:26 AM Subject: Re: [Beaker-devel] Updating the home page blurb for Beaker
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/
I wonder if its worthwhile keeping the distinction of system hardware vs other hardware (i.e monitors), in case people think they can use it as a general inventory store.
- 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:
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.
-- Dan Callaghan dcallagh@redhat.com Software Engineer, Infrastructure Engineering and Development Red Hat, Inc.
Beaker-devel mailing list Beaker-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Version 3 based on Dan's feedback.
- Lead paragraph is gone (in favour of the existing headline text) - I kept the "system hardware details" in the inventory bullet due to the point Ray mentioned - we don't currently support inventorying arbitrary hardware, and I'd prefer to be up front about that. - I expanded "execution environments" to "task execution environments", as we provision more than just the OS, we install Beah, set up various environment variables, install task RPMs, run arbitrary kickstart snippets, etc. - final paragraph mostly replaced with Dan's suggested text. - Retained explicit mention of Anaconda, as Beaker likely won't work with SuSE (due to our reliance on kickstart, where SuSE uses autoyast) - 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.
================================ 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.
Tasks are defined using the Beah task execution framework, a component of Beaker. ================================
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.
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?
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.
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.
Cheers, Nick.
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.
On 01/16/2013 12:01 PM, Dan Callaghan wrote:
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.
Ah, OK - I had misunderstood which layers were emulating what in the current setup. I think given that, it's best to just drop that part of the blurb until we have a good description of the test environment in the docs to link to. Once we have a suitable link destination for "RHTS-compatible", then something like "Beaker currently runs all tasks in an RHTS-compatible execution environment." may work.
Cheers, Nick.
Excerpts from Nick Coghlan's message of 2013-01-16 12:15:15 +1000:
On 01/16/2013 12:01 PM, Dan Callaghan wrote:
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.
Ah, OK - I had misunderstood which layers were emulating what in the current setup. I think given that, it's best to just drop that part of the blurb until we have a good description of the test environment in the docs to link to. Once we have a suitable link destination for "RHTS-compatible", then something like "Beaker currently runs all tasks in an RHTS-compatible execution environment." may work.
+1
On 01/15/2013 11:31 PM, 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.
Not sure if I should start another thread about that, but what about using autotest as an alternative harness to beah? I didn't follow the discussion about defining a harness API (I'll read it during the morning), but what I can remember is, we had some prototype implementations, and people sent me patches, which I applied to autotest to make both systems interact better.
I haven't heard much news after that. Is there anything we could do to help to get the autotest client to play nice with beaker, so it can be used as a harness?
Another subject that I find interesting is how we could make beaker more useful for distros that are not based on rpm. In autotest we have some strategies that make it run in more distros, such as debian based, and we could figure out some solution for beaker.
On 01/16/2013 12:21 PM, Lucas Meneghel Rodrigues wrote:
On 01/15/2013 11:31 PM, 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.
Not sure if I should start another thread about that, but what about using autotest as an alternative harness to beah? I didn't follow the discussion about defining a harness API (I'll read it during the morning), but what I can remember is, we had some prototype implementations, and people sent me patches, which I applied to autotest to make both systems interact better.
I haven't heard much news after that. Is there anything we could do to help to get the autotest client to play nice with beaker, so it can be used as a harness?
STAF and autotest are the two alternate harnesses on my personal wishlist.
I know some folks currently get autotest running by provisioning the host system via beaker, then firing up autotest in a VM. Essentially, they use Beaker as an IaaS to get a KVM capable system, then do their own provisioning for the guest VM.
It's rather clumsy, and also means that Beaker has basically zero visibility into the results of the task in that case - hence the idea in the thread last month about letting an alternate harness pass a URL up to Beaker saying "the real test results are over there".
Another subject that I find interesting is how we could make beaker more useful for distros that are not based on rpm. In autotest we have some strategies that make it run in more distros, such as debian based, and we could figure out some solution for beaker.
The main challenge there is that Beaker's current provisioning and configuration system is coupled really tightly with anaconda kickstarts.
So, rather than trying to make Beaker into a full IaaS solution, it seems to make sense to instead look at VM image based provisioning in *other* IaaS solutions.
We started down this path with the oVirt Engine integration in 0.10 - while the dynamic VM provisioning currently installs the OS from scratch the same way we do in the rest of Beaker, the potential is at least there to also support image-based provisioning.
I actually see the two topics as quite closely related - testing on other distros (or even operating systems) really means supporting VM image based provisioning, but Beah/RHTS also depend on the kickstart files for their configuration, so image based provisioning itself arguably depends on being able to use alternate test harnesses.
Cheers, Nick.
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
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.
beaker-devel@lists.fedorahosted.org
-
Bill Peck -
Dan Callaghan -
Lucas Meneghel Rodrigues -
Nick Coghlan -
Raymond Mancy