Nick Coghlan | 22 Jul 06:40 2014

Defining & documenting Beaker's architecture support levels

Something that came up recently is the question of how we clearly
communicate *how well* Beaker supports different architectures. In
particular, just because we support provisioning something doesn't
necessarily mean we support doing hardware inventory scans on it.

I think the first step in adding something like that to the architecture
guide is to just list out all the features that go into our architecture
support. That's a useful thing to have regardless, and it means we can
potentially go through and create a feature matrix for it (or perhaps
summarise it as a numeric ranking).

On the provisioning side, the items I'm aware of are:

- basic provisioning (i.e. can we boot it at all)
- boot menu (i.e. do we provide a boot menu for manual provisioning)

On the inventory side, the items I'm aware of are:

- basic inventory (i.e. memory, number of CPUs, disk info)
- CPU details (i.e. precise details of the CPU capabilities)

So only x86 and x86_64 would currently get full marks - for everything
else, we don't currently provide full CPU details.

I think this also highlights for me that we *really* want at least a
summary in the architecture guide of what info beaker-system-scan
collects. It doesn't need to be completely detailed in terms of how the
information is reported back to Beaker, but having that list of "what
beaker-system-scan reports back to Beaker" will help explain the purpose
the inventory system serves, and (eventually) what some of the
(Continue reading)

Nick Coghlan | 21 Jul 08:29 2014

Offering lshw based inventory scans for new architectures

As we add new experimental architectures, we're in the situation where
we don't currently have a working inventory scan for those systems,
since newer versions of the operating system that support those
architectures are also missing smolt.

So, here's my question: would it be possible to tweak beaker-system-scan
such that, if smolt is available, we use it in preference to lshw, but
otherwise, we just rely on lshw?

My idea here is that, for existing architectures, we would run the
inventory task on an OS with smolt, to make sure we continue to supply
the same data we always have, until we're sure we have lshw to the point
where it's a suitable replacement.

But for new architectures, supplying whatever lshw can give us today
(along with the rest of the info beaker-system-scan collects) would be
better than nothing, so it makes sense to at least do that, and skip the
parts that depend on smolt.

Does this approach make sense to anyone else? Would it be reasonably
easy to just skip the smolt-based components of the scan when it wasn't



Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
(Continue reading)

Nick Coghlan | 21 Jul 05:19 2014

Dedicated subcommand for hardware scans?

I thought I had filed an RFE for this somewhere along the line, but
apparently not...

Currently, hardware scans are requested via the "--inventory" option to
the "machine-test" subcommand. This is a little(!) obscure for a feature
that powers the entire inventory search capability.

What do folks the think of the idea of adding a dedicated
"update-inventory" subcommand such that "bkr update-inventory" was the
equivalent of "bkr machine-test --inventory --ignore-system-status"?



Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane

HSS Provisioning Architect
Beaker-devel mailing list
Beaker-devel <at>
Alexander Todorov | 18 Jul 12:00 2014

How do I deprecate a workflow?

Hi guys,
how do I go about deprecating workflow-snake ? There is already a replacement 
for it (workflow-installer-test) which uses Jinja2 templates and doesn't need 
the additional piece of infrastructure (SNAKE server).

There's a proof of concept that it is usable (public tier #1 test cases for 

What are the steps (both in code and in process) to deprecate workflow-snake and 
subsequently remove it from beaker-client ?

Beaker-devel mailing list
Beaker-devel <at>
Dan Callaghan | 18 Jul 10:16 2014

Beaker 0.17.1 released

The Beaker 0.17.1 bug fix release is now available from [1].

This release fixes a potential data leak, where system power settings 
were exposed to all authenticated users through CSV export (even if they 
did not have permission to edit the system) [2].

A number of other bug fixes are also included in this release, and new 
versions of the Beah test harness and /distribution/virt/install task 
have been published. As always, please refer to the updated release 
notes for a complete list [3]. The detailed list of all changes made 
since Beaker 0.17.0 is also available [4].



Dan Callaghan <dcallagh <at>>
Software Engineer, Hosted & Shared Services
Red Hat, Inc.
Beaker-devel mailing list
Beaker-devel <at>
Amit Saha | 11 Jul 04:25 2014

Proof of concept: Running tests in a Docker container

I just posted a draft patch for a proof-of-concept that I got working early this week
for running the tests in a Docker container rather on the test system itself:

Considering the ease of running the "restraint" test harness, I have used "restraint" instead
of "beah", Beaker's default test harness.

From a user's perspective, the only change needed is specifying "contained_harness" as a ksmeta

It's draft, so comments/suggestions/questions very welcome.
Beaker-devel mailing list
Beaker-devel <at>
Amit Saha | 10 Jul 03:53 2014

Pre-defined host filters for workflow commands

A new feature for the beaker client - "pre-defined host filters" was 
recently merged into develop and will be released when beaker-0.18 is
released. [1]

It allows you to specify pre-defined host filters to insert custom host
selection criteria instead of having to type in the XML everytime when
using the workflow commands. Further, it allows you to define your own host 
filters or override an existing one [2].



Beaker-devel mailing list
Beaker-devel <at>
Dan Callaghan | 4 Jul 00:25 2014

Unplanned downtime for

Overnight the filesystem for the VM hosting filled 
up. Right now it looks like nothing bad or unusual happened, it is just 
the accumulation of our large yum repos, our many large patchbot 
results, and our many nightly builds (it was actually the nightly build 
that finally filled it up).

I have pruned some nightlies to free up some space, but I am going to 
take the opportunity to perform a thorough audit of the disk space in 
use, upgrade to Fedora 20, expand the disk, and move /srv onto 
a separate volume so that if it fills up in future it doesn't bring the 
whole box grinding to a halt.

Please note that some mails to were rejected (as far 
as I can see they were only spam anyway), there may have been other 
glitches as well. Ping me in #beaker if you see any other issues.


Dan Callaghan <dcallagh <at>>
Software Engineer, Hosted & Shared Services
Red Hat, Inc.
Beaker-devel mailing list
Beaker-devel <at>
Nick Coghlan | 27 Jun 03:38 2014

Simplifying running the inventory task

Currently, doing a hardware scan on a system requires a command line like the following:

    bkr machine-test --inventory --family=RedHatEnterpriseLinux6 --arch=x86_64 --machine=<FQDN>

The "family" part may need to change when using Beaker to manage architectures that RHEL6 doesn't support.
However, due to the fact beaker-system-scan currently still depends on smolt for some features, using
RHEL7 or Fedora instead isn't ideal if RHEL6 supports the hardware.

In order to eventually add a "Scan this system now" button to the web UI, and, equivalently, a simple "bkr
update-inventory <FQDN>" command, I think we may need to move the logic of choosing a preferred distro
family to run the inventory task to the main Beaker server.

Specifically, I'm thinking of a mapping of architecture -> distro family + inventory task, with a default
distro and inventory task to use for unspecified architectures, together with a dedicated server API
*separate* from the normal job submission API, that requested an inventory scan for a particular
machine. The task of choosing which distro to use, and which inventory task to run would then be handled by
the server. 

The purpose of this would be to better enable working with architectures that the default approach can't
handle yet - standard supported architectures would use the default of
/distribution/inventory-on-RHEL-6 (at least until we manage to remove the dependency on smolt, then we
can switch to RHEL7 by default), while experimental architectures could use a different distro, or even a
different inventory task.

By making this admin configurable (include the default distro used), we'd also better support instances
that don't have RHEL trees loaded at all, but only Fedora and/or CentOS.


(Continue reading)

Matt Jia | 24 Jun 02:10 2014

Beaker usage reminder system

I have implemented the beaker usage reminder system proposal[1] and we are planing to include it in beaker
0.18, if there is any feedback or suggestions please send to the list.

Some more discussions on this feature can be found here [2].


Cheers, Matt Jia
Beaker-devel mailing list
Beaker-devel <at>
Raymond Mancy | 20 Jun 01:42 2014

Fwd: Beaker distro list is wrong

Thanks Pavol, Forwarding this to the beaker-dev list.

----- Forwarded Message -----
From: "Pavol Babincak" <pbabinca <at>>
To: "Raymond Mancy" <rmancy <at>>
Sent: Friday, June 20, 2014 2:32:11 AM
Subject: Beaker distro list is wrong

Hi Raymond,

it seems Beaker's list of Tags & Distros[1] are incorrect.

Is direct e-mail best way to solve this or do you have mailing
list/request tracker to contact people who take a care of this?

Anyway here is the list of tags which shouldn't be there:
 - RHEL-5.11-Client-
 - RHEL-5.11-Server-
 - RHEL-5.11-Client-Alpha-1.1
 - RHEL-5.11-Server-Alpha-1.1

They've been created by accident during compose promotion.

There are also couple of Distos:
 - RHEL5.11-Server-20140606.0.n
 - RHEL5.11-Server-20140604.0.n
 - RHEL5.11-Server-20140603.0
 - RHEL5.11-Server-20140603.0.n
 - RHEL5.11-Server-20140602.0
 - RHEL5.11-Server-20140601.0.n
(Continue reading)