A few weeks back, Amit put together a proof of concept for running the
test harness in a container, rather than directly on the host
That proof of concept relies on restraint, the new reference harness,
that is intended to eventually replace beah
At the same time, I don't think restraint is currently getting the level
of review and testing that it needs to mature into a plausible
replacement for beah as the default harness.
I think Amit's proposed patch provides a possible way forward:
1. Accept the initial approach where restraint is the *only* supported
harness when running inside a container. Specifying both
"contained_harness" and "harness" as ks_meta variables should be an
error at this point (side note: 'harness' should also be documented
along with all the other ks_meta variables, with a link to
2. Recommend publishing both beah *and* restraint in the harness repos
for Beaker installations. This will not only make restraint available
for container based testing, but also make it readily available via
"harness=restraint" for normal testing, without needing to add a custom
3. Once we have container based testing working reliably with restraint,
drop the restriction against using alternative harnesses in containers.
The priority at the moment though is to get something working that can
run on an Atomic Host, and still provide a relatively normal execution
environment for the executed tasks. Supporting alternative harnesses
*inside* containers is a nice-to-have that can wait until later - by
flatly disallowing it, we ensure we don't have to spend any time working
on container related issues that don't impact restraint. For the initial
iteration, we can also ignore the question of choosing the base image
used to run the harness, as well as being able to start and stop other
containers on the host.
I've filed an RFE for 0.18 on that basis:
As part of this, we may also want to move restraint from Bill's personal
account on GitHub to the main Beaker project account, but I don't think
that's particularly urgent at this point.
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Architect
On behalf of the Beaker development team, I'm pleased to announce that
Beaker 21.0 is now available from the Beaker web site . Thanks to
everyone who contributed patches and bug reports for this release.
Beaker 21 provides a simpler mechanism for system owners to run hardware
scans on their Beaker systems, reduced to a single click or CLI command.
Accompanying this release, we have also published an overhauled version
of the beaker-system-scan tool. The new version uses lshw rather than
smolt to collect hardware info, and its results are now more accurate
than the previous version in many cases.
There are also a number of other minor enhancements and fixes in this
release. As usual, the release notes  have all the details.
The detailed list of all changes made since Beaker 20.2 is also
Dan Callaghan <dcallagh(a)redhat.com>
Senior Software Engineer, Products & Technologies Operations
Red Hat, Inc.
while I am using Beaker mostly via a web interface, I would appreciate to be able to do some bulk operations with jobs when viewing them in "My Jobs" view. Quite often it would be nice to be able to do Cancel and Delete operations as bulk actions. Now one has to Cancel/Delete each job separately always confirming particular action for each job. I do not know if this is some intension to prevent user from mistakenly deleting/canceling wrong job.
I would imagine that feature can be implemented for example as a new column in jobs list table in "My jobs" view, named like "Bulk action" with select box to select what bulk action user wants to execute. Then checkbox for each row and some confirming button both on top and on the botom of the table. I guess that someone could think of a better solution but this is what I made up when I was thinking about it.
What do you think?