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
From Beaker 23.0 onwards, the Git tags for Beaker releases are GPG
signed. The list of committers' GPG keys is now published here:
https://beaker-project.org/gpg/
For the time being, individual Git commits are not being (rigorously)
signed, due to the fact that we use Gerrit's Rebase-if-necessary
strategy which discards the commit signatures in most cases. There
doesn't seem to be any solution for this.
The Yum repos for server packages now also contain GPG-signed RPM
packages. The RPM signing key is also published on the page above. I've
updated the .repo configs we publish to refer to the new GPG key:
https://beaker-project.org/yum/beaker-server-RedHatEnterpriseLinux.repo
[beaker-server]
name=Beaker Server - RedHatEnterpriseLinux$releasever
baseurl=https://beaker-project.org/yum/server/RedHatEnterpriseLinux$release…
enabled=1
gpgcheck=1
gpgkey=https://beaker-project.org/gpg/RPM-GPG-KEY-beaker-project
If you are consuming server packages from beaker-project.org you may
wish to update your Yum configuration as above to enable GPG signature
checking.
Note that only the server repo is signed. The server-testing repo
contains unsigned packages. The client repo is also unsigned but we will
work towards switching this over to be signed in future.
--
Dan Callaghan <dcallagh(a)redhat.com>
Senior Software Engineer, Products & Technologies Operations
Red Hat
Starting from 14 September ~06:30 UTC up until just now, the yum repos
on beaker-project.org were not working properly. Trying to install from
them would yield errors like this:
https://beaker-project.org/yum/server/RedHatEnterpriseLinux6Server/beaker-c…:
[Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 403
Forbidden"
That was due to a mistake in a patch I merged yesterday, which cause the
files to end up on disk with mode 0600 which means Apache was not able
to serve them. Sorry about that.
I have fixed up the wrong permissions just now, if you see any further
problems with these yum repos please hit reply.
--
Dan Callaghan <dcallagh(a)redhat.com>
Senior Software Engineer, Products & Technologies Operations
Red Hat
On behalf of the Beaker development team, I'm pleased to announce that
Beaker 23.2 was released last week [1]. Thanks to everyone who
contributed patches and bug reports for this release. (And my apologies
for this belated announcement!)
Beaker 23.2 is a maintenance release which fixes two important
regressions in 23.0 affecting the initial watchdog time and the
authentication behaviour of the lab controller daemons. A number of
minor fixes are included too. Full details are, as always, available in
the release notes [2].
[1] https://beaker-project.org/releases/
[2] https://beaker-project.org/docs/whats-new/release-23.html#beaker-23-2
--
Dan Callaghan <dcallagh(a)redhat.com>
Senior Software Engineer, Products & Technologies Operations
Red Hat