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
Excerpts from Petr Schindler's message of 2016-08-18 15:59 +02:00:
> Hi Dan,
>
> I'm working on a task for taskotron which should import new composes to
> our Fedora's beaker. But I can't find a xml-rpc call for importing it
> here [0]. There was probably function add_distro_tree(distro) which I
> found in old code I'm editing. I've seen that you added distro trees to
> beaker.qa.fp.org by xmlrpc so I guess there is some way. Could you help
> me with that? Thank you.
Currently it's expected that the trees are imported by running
beaker-import command on the lab controller (in the case of Fedora's
Beaker that's the same machine as the Beaker server). You can't invoke
an XMLRPC call directly to import the distro -- not unless you also
parse out all the metadata from .composeinfo and .treeinfo, which
beaker-import has a lot of code to do.
That design (running beaker-import on the LCs) makes sense for how our
internal Beaker deployment works. But I can see it's obviously not ideal
for what you are trying to do, importing new trees triggered by
Taskotron.
In future we are planning to basically eliminate the "importing" step
entirely, in favour of directly looking up trees in PDC.
In the short term could you do something like, make the Taskotron task
ssh to Beaker and invoke beaker-import? Or maybe trigger an Ansible
playbook (through the RBAC stuff) which invokes beaker-import, with the
necessary URLs passed in as an Ansible var through -e?
--
Dan Callaghan <dcallagh(a)redhat.com>
Senior Software Engineer, Products & Technologies Operations
Red Hat
Hi,
On behalf of the Beaker development team, I'm pleased to announce that
Beaker 23.1 is now available from the Beaker web site [1]. Thanks to
everyone who contributed patches and bug reports for this release.
Beaker 23.1 is a maintenance release which ships important bug fixes.
Full details are available in our release notes [2].
[1] https://beaker-project.org/releases/
[2] https://beaker-project.org/docs/whats-new/release-23.html#beaker-23-1
Happy Testing,
--
Róman Joost
Software Engineer, PnT DevOps - Developer (Brisbane)
email: rjoost(a)redhat.com | tz: UTC+10 | GPG ID: 0x7A3AD3DE at pgp.mit.edu
irc: #beaker #tps-devel