Future directions for the Beaker test harness
by Nick Coghlan
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
6 years
Using shell "if" to conditionalize snippet inclusion is error-prone?
by Jun'ichi Nomura
Hi,
In beaker 0.18, "rhts_post" snippet has a following construct:
if [ -f /etc/sysconfig/readahead ] ; then
{% snippet 'readahead_sysconfig' %}
fi
This is error-prone because if we have site-local "readahead_sysconfig"
snippet, which is empty, generated shell script will be broken.
(Actually, I've been using empty "readahead_sysconfig" snippet)
So it might be better to move if/then/fi into the snippet like below.
Same might apply to "virt_console_post".
---
Jun'ichi Nomura, NEC Corporation
diff --git a/Server/bkr/server/snippets/readahead_sysconfig b/Server/bkr/server/snippets/readahead_sysconfig
index 830f20b..393c215 100644
--- a/Server/bkr/server/snippets/readahead_sysconfig
+++ b/Server/bkr/server/snippets/readahead_sysconfig
@@ -1,3 +1,4 @@
+if [ -f /etc/sysconfig/readahead ] ; then
cat >>/etc/sysconfig/readahead <<EOF
# readahead conflicts with auditd, see bug 561486 for detailed explanation.
@@ -8,3 +9,4 @@
READAHEAD_COLLECT="no"
READAHEAD_COLLECT_ON_RPM="no"
EOF
+fi
diff --git a/Server/bkr/server/snippets/rhts_post b/Server/bkr/server/snippets/rhts_post
index bce2347..1635406 100644
--- a/Server/bkr/server/snippets/rhts_post
+++ b/Server/bkr/server/snippets/rhts_post
@@ -15,9 +15,7 @@ fi
# Enable post-install boot notification
{% snippet 'post_anamon' %}
-if [ -f /etc/sysconfig/readahead ] ; then
{% snippet 'readahead_sysconfig' %}
-fi
{% snippet 'linkdelay' %}
{# We normally want to make sure the system time is accurate, in case
9 years, 4 months
Adding resource management to beaker
by Bill Peck
Hello Beaker,
One of the jobs we run uses shared storage. For example:
HostA with Driver1
HostB with Driver2
HostC with Driver3
All connected to StorageX.
We can't run the test on more than one host at a time since it would
conflict.
Being able to specify the following in the job xml is the goal:
<recipeSet>
<recipe/> <!-- Require HostA -->
<resource/> <!-- Require StorageX -->
</recipeSet>
<recipeSet>
<recipe/> <!-- Require HostB -->
<resource/> <!-- Require StorageX -->
</recipeSet>
<recipeSet>
<recipe/> <!-- Require HostC -->
<resource/> <!-- Require StorageX -->
</recipeSet>
I know there is a resource type for recipe but this doesn't seem like a
good solution. I did try an experiment where I created StorageX host in
beaker with no power control and scheduled three recipesets like above.
But this hack won't work because a watchdog with a NULL expire time is
set and that means it will sit there forever. Even if it did work,
maybe if we created a dummy power type, we would still end up with an abort.
I don't think it would take much work to support this type of
multi-host/resource requirement.
Right now we have the following model
Object Recipe, which has the following attributes: distro_tree,
resource, rendered_kickstart, watchdog, systems, dyn_systems, tasks,
dyn_tasks, tags, repos, rpms, logs, custom_packages, ks_appends
Object MachineRecipe which inherits from Recipe, and adds a guests
attribute.
Object GuestRecipe which inherits from Recipe.
A ResourceRecipe object wouldn't need most of these attributes, probably
just the following:
resource, systems, and dyn_systems. (no watchdog, just return when
recipeSet completes or aborts)
And resource currently maps to a RecipeResource which can be one of the
following:
SystemResource
VirtResource
GuestResource
I think adding another Object here would make sense, but the term
Resource is overused and its a little confusing right now.
If done correctly we could re-use the filtering code in needproperty,
but I think the only things we could search on for resources would be
the following: Name, lab_controller, and key_values? (storing how these
shared resources are connected would be another option I suppose, but
maybe too complicated for a first implementation?)
I'm sure there are other things to consider, we could support setting up
and tearing down shared resources (almost like a power on/off command).
I want to be mindful of things like that but I don't want to be
paralysed with what if's and never get anything done.
I know you guys have been working hard on the groups features and want
to re-do the scheduler as well. Maybe this would be something for after
the scheduler re-write? I don't see any mention of this on the roadmap
[1] (although the roadmap is quite full already!).
In any event, I'm interested in hearing your ideas and feedback.
Thanks!
1 - http://beaker-project.org/dev/tech-roadmap.html
9 years, 5 months
Upcoming feature: Running Test harness in a Docker Container
by Amit Saha
Hi all,
We recently merged a new feature into the "develop" branch which allows
running the test harness in a Beaker container [1].
During the testing, I used the "restraint" [2] test harness instead of Beaker's
default test harness, "beah". "restraint" is not available from Fedora's repos
so the repository has to be added in the Job XML.
Here is an example recipe which runs the test harness in a container running Fedora 20:
https://gist.github.com/amitsaha/fc7c686e897a2d921a2f
The key points in the above recipe for this feature are:
- "contained_harness" ksmeta variable: This tells beaker that we want to run the test harness
in a Docker container.
- The restraint repo is added using the <repo/> element.
- The task to be run is added in the <task/> elements.
Since this recipe does not specify which distro image to use for the test harness container,
we default to Fedora 20.
To specify a different image, use the "harness_docker_base_image" ksmeta
variable. For example, the following recipe will run the test harness in a CentOS 7 container while
the host system is running Fedora 20: https://gist.github.com/amitsaha/aebe0e782a47063e9270
As mentioned in [1], a privileged Docker container is used to run the test harness and by default
we use "systemd" to initialize the test harness. Hence it is the harness's responsibility to
register/install itself in the right target.
This can however be changed with the "contained_harness_entrypoint" ksmeta variable.
See [3] for a brief explanation on this and the other ksmeta variables.
This is an experimental feature and currently the following limitations apply:
- Tests which reboot are not supported
- Tests which may want to spawn other containers are not supported as well
- Distros with SysV init hasn't been tested
- Beaker's default test harness, beah hasn't been tested
- .. others I am sure.
[1] https://beaker-project.org/docs-develop/whats-new/next/test-harness-in-co...
[2] http://restraint.readthedocs.org
[3] https://beaker-project.org/docs-develop/user-guide/customizing-installati...
Best,
Amit.
--
Amit Saha
SED, Hosted & Shared Services
Red Hat, Inc.
9 years, 5 months