Beaker-devel January 2017

beaker-devel@lists.fedorahosted.org

5 participants
3 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

Beaker 24.0 released
by Róman Joost 31 Jan '17

31 Jan '17

Hello! On behalf of the Beaker development team, I'm pleased to announce that Beaker 24.0 is now available from the Beaker web site [1]. Thanks to everyone who contributed patches and bug reports for this release. Beaker 24 brings improved OpenStack integration, conditional reservations, and many other improvements. Full details are available in our release notes [2]. The detailed list of all changes made since Beaker 23 is also available [3]. [1] https://beaker-project.org/releases/ [2] https://beaker-project.org/docs/whats-new/#beaker-24 [3] https://git.beaker-project.org/cgit/beaker/log/?qt=range&q=beaker-23.0..bea… Happy Testing, -- Róman Joost Software Engineer, PnT DevOps - Developer (Brisbane) email: rjoost(a)redhat.com | tz: UTC+10 | GPG ID: 0xBE2B559D at pgp.mit.edu irc: #beaker

4 4

[PATCH] distro_import: Suggested interim fix for RHEL7 TreeInfo importer
by Jon Masters 22 Jan '17

22 Jan '17

Current upstream Beaker breaks when given a RHEL7 os directory using a ".treeinfo". It probably works fine with a ".composeinfo", which I know is preferred now, but when attempting to import a released ISO (such as by end users) only a treeinfo is available for the import. This temporary hack simply knows about the "Server" and also the "Server-optional" repos. It doesn't know about all of the variants and probably needs work (for example, to use the class provided variant-%s data that you have as in composeinfo parsing), or you might throw it away entirely. Mostly sending this to flag that the current treeinfo parsing is broken and doesn't work. I'm using a version of this hack in production in my Beaker with RHEL7 based aarch64 composes added using treeinfo. Signed-off-by: Jon Masters <jcm(a)jonmasters.org> --- LabController/src/bkr/labcontroller/distro_import.py | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/LabController/src/bkr/labcontroller/distro_import.py b/LabController/src/bkr/labcontroller/distro_import.py index faad616..6e70c40 100755 --- a/LabController/src/bkr/labcontroller/distro_import.py +++ b/LabController/src/bkr/labcontroller/distro_import.py @@ -1473,7 +1473,24 @@ def is_importer_for(cls, url, options=None): def find_repos(self): repos = [] - try: + + repo_paths = [('Server', + 'variant', + '.'), + ('Server-optional', + 'optional', + '../../../Server-optional/%s/os/' % self.tree['arch'])] + + for repo in repo_paths: + if url_exists(os.path.join(self.parser.url,repo[2],'repodata')): + repos.append(dict( + repoid=repo[0], + type=repo[1], + path=repo[2], + ) + ) + + try: addons = self.parser.get('variant-%s' % self.tree['variant'], 'variants') addons = addons.split(',') for addon in addons: -- 2.5.5

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Beaker-devel January 2017