Hi Nick,
Thanks for the notes and suggestions.
----- Original Message -----
From: "Nick Coghlan" ncoghlan@redhat.com To: "beaker-devel" beaker-devel@lists.fedorahosted.org Sent: Tuesday, August 19, 2014 5:18:02 PM Subject: [Beaker-devel] Future directions for the Beaker test harness
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:
- 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/).
- 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.
Yes, this will certainly make using restraint easier than it is currently.
- 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.
Two points related to the last sentence:
1. If we do not allow selecting the base image, we are effectively *not* obeying the distro selection in the job unless of course both are the same.
2. If we start the container with /run volume mounted, running other containers on the host will be possible and so will be restarting the host. We *could* make this always the case or have an option to enable it.
Best, Amit.