Beaker-devel October 2014

beaker-devel@lists.fedorahosted.org

5 participants
6 discussions

Future directions for the Beaker test harness
by Nick Coghlan 12 Mar '18

12 Mar '18

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

5 10

Using shell "if" to conditionalize snippet inclusion is error-prone?
by Jun'ichi Nomura 03 Nov '14

03 Nov '14

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

2 4

Atomic Host + cloud init
by Amit Saha 21 Oct '14

21 Oct '14

Came across this today: http://www.projectatomic.io/blog/2014/10/getting-started-with-cloud-init/ I think this should now make it possible to use atomic images as well in Beaker now that we have cloud install task. -- Amit Saha SED, Hosted & Shared Services Red Hat, Inc.

1 0

Adding resource management to beaker
by Bill Peck 21 Oct '14

21 Oct '14

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/>  <resource/>  </recipeSet> <recipeSet> <recipe/>  <resource/>  </recipeSet> <recipeSet> <recipe/>  <resource/>  </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

2 2

Upcoming feature: Running Test harness in a Docker Container
by Amit Saha 08 Oct '14

08 Oct '14

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-cont… [2] http://restraint.readthedocs.org [3] https://beaker-project.org/docs-develop/user-guide/customizing-installation… Best, Amit. -- Amit Saha SED, Hosted & Shared Services Red Hat, Inc.

4 8

Upcoming feature: Support for provisioning Atomic hosts
by Amit Saha 08 Oct '14

08 Oct '14

Hi all, We recently merged support for provisioning Atomic hosts [1, 2 ] in Beaker ("develop" branch). The main difference from running tests on a "traditional" distro is that the tests are executed in a Docker container instead of bare metal. Here is an example job: https://gist.github.com/amitsaha/dd7cdb16ed862cb259fd This assumes that you have an atomic host "MyAtomicHost" already imported in your Beaker installation and has identified itself to be supporting "rpm-ostree" by using the "has_rpmostree" distro feature variable [3]. The key ksmeta variables from the above recipe are: * harness_docker_base_image=registry.hub.docker.com/fedora:20 This specifies the docker base image for the container. * ostree_repo_url=http://link/to/ostree/repo/ rpm-ostree repository * ostree_ref=my-atomic-host/20/x86_64/standard rpm-ostree remote ref. This builds upon the recently merged "Running test harness in a Docker container" feature [4]. [1] http://www.projectatomic.io [2] https://beaker-project.org/docs-develop/whats-new/next/provision-atomic.html [3] https://beaker-project.org/docs-develop/user-guide/customizing-installation… [4] https://lists.fedorahosted.org/pipermail/beaker-devel/2014-October/001095.h… Best, Amit. -- Amit Saha SED, Hosted & Shared Services Red Hat, Inc.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Beaker-devel October 2014