Beaker-devel September 2017

beaker-devel@lists.fedorahosted.org

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

returning system activity table information.
by Shawn Doherty 02 Oct '17

02 Oct '17

Hello. I was hoping someone had an idea on the best way to get activity information from a system in beaker. My situation is that I am trying to incorporate parts of the Beaker CLI in a bash script to automate Request Tracker work. Part of this would require getting the activity history from a requested system. I didn't find anything suitable when looking through the Beaker CLI. wget wasn't returning the information that I needed from a call to #history. I'm throwing this out there to see if anyone on the list had any suggestions. Looking specifically for getting the information on User and Action:Returned. Thanks, Shawn -- Shawn Doherty Software Engineer, Kernel-HW Red Hat <https://www.redhat.com> 314 Littleton Rd Westford, MA 01886 sdoherty(a)redhat.com T: 19785891080 INTERNAL:-8131080 IM: sdoherty <https://red.ht/sig>

4 4

Patches in need of review
by Don Zickus 28 Sep '17

28 Sep '17

Hi Dan, Shawn and Jon have posted their firmware changes in Gerrit (for beaker, beaker-in-a-box, beaker-systemscan). We haven't seen much in the way of a review or update in a week or two. Any timetable when we can expect to have you or someone on your team be available to comment on the patches? Thanks! Cheers, Don

2 1

RFE: Allow installation of a user-defined distro that is not registered in Beaker
by Anwesha Chatterjee 28 Sep '17

28 Sep '17

Hello all, I have been working on the feature mentioned in: *Bug 911515 - RFE: Allow installation of distros which are not imported in beaker*, and have written a proposal [1] about the functionality. Please feel free to read the document and leave your feedback in here or in the bugzilla [2]. [1] https://beaker-project.org/dev/proposals/allow-installation-user-defined-di… [2] https://bugzilla.redhat.com/show_bug.cgi?id=911515 *Thanking you,* *Anwesha Chatterjee* *Software Engineer* *Red Hat - Brisbane*

4 5

Re: temporary way of booting custom kernel and initrd in Beaker today
by Dan Callaghan 26 Sep '17

26 Sep '17

On Fri, Aug 18, 2017 at 10:45 AM, Jan Stancek <jstancek(a)redhat.com> wrote: > Hi, > > Jeff&I arrived to an idea how (maybe) we could start playing with > booting custom kernel/initrd today: > > We create a custom distro, for example we copy Fedora26 with different > name: "SKT26", and we place it somewhere where we have RW access to it. > Then we import it to Beaker manually. > > If my understanding of Beaker is correct, we can freely replace > kernel/initrd in our distro and Beaker will always copy latest > files to tftp when we run a job. > > Obviously the problem is concurrency and reproducibility of jobs, > but it would a quick way to allow us experimenting with custom > kernels/initrds today. > > Any comments/thoughts? Yes I think this should work and would be a good workaround for the short term. We would just need to make sure that the new fake distro tree is not picked up by beaker-pxemenu to be included in the PXELINUX menu. If it is included in the menu, the kernel+initrd will be cached on the LC and beaker-provision will just re-use the cached images instead of re-downloading them each time. Excerpts from Hannes Frederic Sowa's message of 2017-08-19 18:49 -04:00: > What about synchronizing /lib/modules directory with initrd + vmlinuz? > In a lot of cases we depend on dynamically loaded modules even during > testing phase. Is this also possible with this schema? > > Thanks for looking into this, > Hannes This is a good point. I guess it is not enough to just replace pxeboot/vmlinuz and pxeboot/initrd.img, but also the kernel-related packages (and the Anaconda stage2.img as well?) -- almost an entire new compose in place each time. Which begs the question... if you are doing an entirely new compose each time, whys not just register each one in Beaker separately? Let's continue the discussion on the devel list (cc'ed) so others can see. Coincidentally Anwesha has just started working on proper support for "user-supplied distro trees" in bug 911515 so we should see some progress on that soon. -- Dan Callaghan <dcallagh(a)redhat.com> Senior Software Engineer, Products & Technologies Operations Red Hat

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Beaker-devel September 2017