Beaker-devel October 2015

beaker-devel@lists.fedorahosted.org

4 participants
4 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 21.1 released
by Dan Callaghan 23 Nov '15

23 Nov '15

On behalf of the Beaker development team, I'm pleased to announce that Beaker 21.1 is now available from the Beaker web site [1]. Thanks to everyone who contributed patches and bug reports for this release. (The release was actually published on 21 October, I apologies for the lateness of this announcement.) This release includes an assortment of bug fixes and minor enhancements, including a fix for a regression in the broken system detection logic in 21.0. Full details are in the release notes [2]. The detailed list of all changes made since Beaker 21.0 is also available [3]. [1] https://beaker-project.org/releases/ [2] https://beaker-project.org/docs/whats-new/release-21.html#beaker-21-1 [3] https://git.beaker-project.org/cgit/beaker/log/?qt=range&q=beaker-21.0..bea… -- Dan Callaghan <dcallagh(a)redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat, Inc.

2 1

Proposed changes to recipe set ack/nak/comments
by Dan Callaghan 04 Nov '15

04 Nov '15

The user interface improvements for the job page and recipe page [1] have been in planning/discussion for quite a while now, but recently the team has been making good progress on prototyping the new interfaces with a view towards implementing them in Beaker 22.0. One issue we ran up against while prototyping the job page was how to handle the ack/nak/comment functionality for recipe sets. In the original design document we essentially hand-waved past this but when it came down to actually implementing something we realised the current UI with a tri-state selector plus comment modal does not fit in with the new design, and it offers a very subpar user experience as well. After some discussion the Beaker development team came up with the following plan for tackling the ack/nak/comment issues: * The comment functionality will be separated out from ack/nak and fully fleshed out, supporting multiple comments from different users and recording the commenting user and timestamp. It will also be expanded to support commenting on tasks and results, which was one of the key requested items for Beaker 22.0. * The original design proposal for the job page improvements mentioned allowing ack/nak/comment on recipes, tasks, and results. However it's not clear what the meaning or behaviour of a nak at one of these lower levels should be, and also unclear if nack'ing individual results is even useful or desirable, so we will defer this. For now, ack/nak will only apply to recipe sets as it does now. * The terms "ack" and "nak"/"nack" have no precedent in other testing systems and their meaning is unclear to new users. The "nak" setting will be renamed to "waived" in line with its intended meaning. However the existing response="nak" attribute in the job results XML will be preserved for compatibility. * The distinction between "needs review" and "ack" does not seem useful so it will be removed. All recipe sets will effectively by "acked" by default. (Recipe sets with a Pass result are already acked by default right now.) In particular this means the operation of changing a failed recipe set from "needs review" to "ack" will no longer be possible. The only operation will be "waive" which is equivalent to nack'ing a recipe set, or "un-waive" to reverse it. If you see any issues with the above, or if you think it might break your workflows, please hit reply. [1] https://beaker-project.org/dev/proposals/job-page-improvements.html -- Dan Callaghan <dcallagh(a)redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat, Inc.

3 6

Archived job logs on Beaker
by Jan Stourac 22 Oct '15

22 Oct '15

Hello there, regarding to "retention tag" feature which Beaker provides there are options like "audit" and "active" that are tied with particular product. I would like to ask whether there is some place in Beaker web-gui that allows me to see all archived executed jobs (and their logs) for particular product so one do not have to save links or job-ids somewhere else to find appropriate logs. Yes I have those jobs in my view, but in case there are more users that may execute such jobs this is not quite useful. I have found that there is Beaker client feature to get links to all logs for particular job, "bkr job-logs J:<job-id>" but I haven't found whether I can specify product name to get e.g. links to executed jobs. Neither I have found this feature available via Beaker web-gui. Does someone know wheter there is such feature? Am I missing something? Thanks in advance for any advice, Jan

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Beaker-devel October 2015