Nick Coghlan | 19 Aug 09:18 2014
Picon

Future directions for the Beaker test harness

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.

(Continue reading)

Amit Saha | 14 Aug 07:11 2014
Picon

Beaker 0.17.3 released

On behalf of the Beaker developers, I am pleased to announce that 
the Beaker 0.17.3 maintenance release is now available from
beaker-project.org [1].

This release introduces GRUB2 netboot support for PPC64 systems,
fixes a regression and some other bugs [2].

[1] https://beaker-project.org/releases/
[2] https://beaker-project.org/docs/whats-new/release-0.17.html#beaker-0-17-3

Best,
Amit.

--

-- 
Amit Saha 
SED, Hosted & Shared Services
Red Hat, Inc.
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Nick Coghlan | 6 Aug 10:43 2014
Picon

Feature requests for system performance monitoring

I thought we had some open feature requests for being able to monitor
system performance while tasks were running. After seeing the
"Performance Co-Pilot" talk at PyCon AU, I'm wondering whether we might
be able to come up with a task that allows PCP monitoring to be enabled
on the system under test and the logs uploaded for later analysis (we'll
need to be careful with this, since it could easily overwhelm the log
server if used indiscriminately).

However, I can't find the relevant RFEs. That may just be a search
failure on my part, though, so I figured I'd check if anyone else
remembered such a thing.

Cheers,
Nick.

--

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

HSS Provisioning Architect
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Nick Coghlan | 22 Jul 06:40 2014
Picon

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
Picon

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
available?

Cheers,
Nick.

--

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

Nick Coghlan | 21 Jul 05:19 2014
Picon

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"?

Cheers,
Nick.

--

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

HSS Provisioning Architect
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Alexander Todorov | 18 Jul 12:00 2014
Picon

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 
Fedora).

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

--
Alex
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Dan Callaghan | 18 Jul 10:16 2014
Picon

Beaker 0.17.1 released

The Beaker 0.17.1 bug fix release is now available from 
beaker-project.org [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].

[1] https://beaker-project.org/releases/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1116722
[3] https://beaker-project.org/docs/whats-new/release-0.17.html#beaker-0-17-1
[4] https://git.beaker-project.org/cgit/beaker/log/?qt=range&q=beaker-0.17.0..beaker-0.17.1&showmsg=1

--

-- 
Dan Callaghan <dcallagh <at> redhat.com>
Software Engineer, Hosted & Shared Services
Red Hat, Inc.
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Amit Saha | 11 Jul 04:25 2014
Picon

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:
http://gerrit.beaker-project.org/#/c/3199/

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
variable.

It's draft, so comments/suggestions/questions very welcome.
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Amit Saha | 10 Jul 03:53 2014
Picon

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].

[1] https://beaker-project.org/docs-develop/whats-new/next/workflow-preset-host-filters.html
[2] https://beaker-project.org/docs-develop/man/bkr.html#cmdoption-bkr--host-filter

Best,
Amit.

_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
Dan Callaghan | 4 Jul 00:25 2014
Picon

Unplanned downtime for beaker-project.org

Overnight the filesystem for the VM hosting beaker-project.org 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 beaker-project.org 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> redhat.com>
Software Engineer, Hosted & Shared Services
Red Hat, Inc.
_______________________________________________
Beaker-devel mailing list
Beaker-devel <at> lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel

Gmane