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
5 years, 8 months
Re: temporary way of booting custom kernel and initrd in Beaker today
by Dan Callaghan
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
6 years, 2 months
Self Introduction
by Anwesha Chatterjee
Hello everyone,
Just wanted to do a quick introduction for myself.
I'm Anwesha and I'm a software engineer who has recently started working in
the Beaker team - so you may come across my name in bugzilla and other
Beaker-related places - see you guys around!
*Thanking you,*
*Anwesha Chatterjee*
*Software Engineer*
*Red Hat - Brisbane*
6 years, 3 months
Adding custom initrds to beaker tftp boot
by Don Zickus
Hi Dan,
I am playing with some KernelCI stuff and one of the topics is fast
booting/installs of a new kernel. The thought is waiting 20-25 minutes to
install Anaconda is too long, when you are resource constrained and need to
run 30-40 tests/day on the same hardware.
An idea came up about creating a custom kernel and initrd with a testsuite
builtin. Currently I don't think beaker supports that, only pre-loaded
distro kernels/initrds.
How hard is it to add that to the LabController? Or some other alternative?
Cheers,
Don
6 years, 4 months