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
That proof of concept relies on restraint, the new reference harness,
that is intended to eventually replace beah
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
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
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:
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.
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Architect
Shawn is working with Jon and myself to add system firmware/bios info to the
beaker database to be displayed on the system details page.
The idea was to make it easy to find how old a bios is on our lab machines
and see which ones need an update.
Shawn made all the front end changes in the inventory job, but the backend
work is becoming a challenge.
It seems like we are going to have to add a table entry to the database in
server/model/inventory.py? Which would probably cause a database migration
For now, we are using numa_nodes as our template to copy the output of lshw
(from the inventory script) into the database and onto the webpage.
Are we going in the right direction? Is this more work than we thought?
Then as a follow-on, we are assuming the database has to be updated to add
this entry, would it make sense to convert the whole database to a generic
key/value table to dynamically support new fields without having to migrate
the whole database all the time? And then to prevent random junk from being
added by the inventory script (or other script), have a whitelist filter
that only allows certain keys to be added/updated. Maintaining the
whitelist would be easier on the database then adding table entries.
This is just us trying to understand the architecture a little more and
trying to see where we can add some value to make it easier to maintain our
I have a question regarding WebDriver testing. I was working on creating
an integration test. When I would change code in the widgets.py file, my
integration test was not responsive to my changes, and seemed to be holding
on to information from previous versions.
Is there a cache in the webdriver or something that needs to be updated
when we make a change?
Software Engineer, Kernel-HW
314 Littleton Rd
Westford, MA 01886
sdoherty(a)redhat.com T: 19785891080 INTERNAL:-8131080 IM: sdoherty
Anyone else think it is odd that the backend server state for a machine
entry can change, example schedule setting, and the front end UI doesn't
either get a push update or a 409 conflict error?
Is there a bug filed for this?
A recurring theme we seem to encounter when working through various features
we want to implement in beaker, is the challenges the front-end poses to add
code. It isn't just a straight-forward add code (once you understand the
technology), but there is an added bonus of understanding the strange quirks
the legacy code is laying upon the current code. :-) But you already know
I wanted to reach out and understand what the initial thoughts were to
migrate away from the legacy stuff. Obviously your team made an initial
effort and stopped. And there is still plenty of work to be done. Was a
process to move forward ever documented?
Granted things are a little bit better now that we understand how to run the
server in developer mode better and have the corresponding lengthy
dependencies installed. But I still struggle just to convert one page to
strictly flask and still involves using kid files to pass back to
With all the changing technology out there, it would be nice to have beaker
be updated easily to match our needs. So I was trying to wrap my head
around an easy process to migrate things to a better place.