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
(http://gerrit.beaker-project.org/#/c/3199)
That proof of concept relies on restraint, the new reference harness,
that is intended to eventually replace beah
(https://beaker-project.org/dev/proposals/reference-harness.html)
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
https://beaker-project.org/docs/alternative-harnesses/)
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
repo definition.
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:
https://bugzilla.redhat.com/show_bug.cgi?id=1131388
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.
Regards,
Nick.
--
Nick Coghlan
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.1 is now available from the Beaker web site [1]. Thanks to
everyone who contributed patches and bug reports for this release.
(The release was actually published on 21 October, I apologies for the
lateness of this announcement.)
This release includes an assortment of bug fixes and minor enhancements,
including a fix for a regression in the broken system detection logic in
21.0. Full details are in the release notes [2].
The detailed list of all changes made since Beaker 21.0 is also
available [3].
[1] https://beaker-project.org/releases/
[2] https://beaker-project.org/docs/whats-new/release-21.html#beaker-21-1
[3] https://git.beaker-project.org/cgit/beaker/log/?qt=range&q=beaker-21.0..bea…
--
Dan Callaghan <dcallagh(a)redhat.com>
Senior Software Engineer, Products & Technologies Operations
Red Hat, Inc.
Hi,
I'd like to share a work in progress I'm using daily to hack on Beaker.
It's a docker container providing a full development environment to run
tests and the Beaker server.
Documentation:
https://git.beaker-project.org/cgit/~rjoost/beaker-docker/tree/README.md
Repository:
https://git.beaker-project.org/cgit/~rjoost/beaker-docker
The container is not available on docker-hub or any repository, so
you'll have to build it yourself. It is using an ansible playbook
creating the environment, which could also be employed against a
different form of provisioning (e.g. libvirt, vagrant, packer,
whatever).
Once started, it provides a full development environment with all
dependencies installed and needed to run all tests and compile
documentation. A playbook is provided as well, to initialise the Server
in order to run it.
I'd like to ask for feedback if people are keen to try it out. Is there
something missing? Are you running into problems creating the container?
The aim is, that you'll need as little effort as possible to set this up
to hack on Beaker.
Thanks and Kind Regards,
--
Róman Joost
Software Engineer, PnT DevOps - Developer (Brisbane)
email: rjoost(a)redhat.com | tz: UTC+10 | GPG ID: 0xBE2B559D at pgp.mit.edu
irc: #beaker
The user interface improvements for the job page and recipe page [1]
have been in planning/discussion for quite a while now, but recently the
team has been making good progress on prototyping the new interfaces
with a view towards implementing them in Beaker 22.0.
One issue we ran up against while prototyping the job page was how to
handle the ack/nak/comment functionality for recipe sets. In the
original design document we essentially hand-waved past this but when it
came down to actually implementing something we realised the current UI
with a tri-state selector plus comment modal does not fit in with the
new design, and it offers a very subpar user experience as well.
After some discussion the Beaker development team came up with the
following plan for tackling the ack/nak/comment issues:
* The comment functionality will be separated out from ack/nak and
fully fleshed out, supporting multiple comments from different users
and recording the commenting user and timestamp. It will also be
expanded to support commenting on tasks and results, which was one of
the key requested items for Beaker 22.0.
* The original design proposal for the job page improvements mentioned
allowing ack/nak/comment on recipes, tasks, and results. However it's
not clear what the meaning or behaviour of a nak at one of these lower
levels should be, and also unclear if nack'ing individual results is
even useful or desirable, so we will defer this. For now, ack/nak will
only apply to recipe sets as it does now.
* The terms "ack" and "nak"/"nack" have no precedent in other testing
systems and their meaning is unclear to new users. The "nak" setting
will be renamed to "waived" in line with its intended meaning. However
the existing response="nak" attribute in the job results XML will be
preserved for compatibility.
* The distinction between "needs review" and "ack" does not seem useful
so it will be removed. All recipe sets will effectively by "acked" by
default. (Recipe sets with a Pass result are already acked by default
right now.)
In particular this means the operation of changing a failed recipe set
from "needs review" to "ack" will no longer be possible. The only
operation will be "waive" which is equivalent to nack'ing a recipe
set, or "un-waive" to reverse it.
If you see any issues with the above, or if you think it might break
your workflows, please hit reply.
[1] https://beaker-project.org/dev/proposals/job-page-improvements.html
--
Dan Callaghan <dcallagh(a)redhat.com>
Senior Software Engineer, Products & Technologies Operations
Red Hat, Inc.