Beaker-devel August 2013

beaker-devel@lists.fedorahosted.org

6 participants
13 discussions

Docs/overview for using autotest in Beaker?
by Nick Coghlan 05 Dec '13

05 Dec '13

Hi Don, Bill, LMR, I saw that the pull request for Beaker harness API support in autotest has been merged. I'd like to link to that feature from beaker-project.org, so I was wondering if there was anything published anywhere (even a blog or mailing list post) that covered the details of: 1. What to add to a job/recipe definition to specify autotest as the harness 2. What, if anything, to add to the task list in the recipe to configure autotest appropriately 3. What, if anything, to include in an autotest job to make it suitable for running inside Beaker 4. How the result reporting works when using autotest as a harness inside Beaker (Do the results just go to Beaker? Or does normal autotest reporting still happen as well?) If there isn't, we'd be happy to accept a patch on Gerrit to add an autotest section to http://beaker-project.org/docs/alternative-harnesses/ :) Somewhat related, is there a tentative date yet for the next autotest release? Cheers, Nick. -- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

5 20

Beaker's tests on Fedora rawhide: 19-08-2013
by Amit Saha 01 Sep '13

01 Sep '13

Hello all, Starting this week, I will post an email like this one every Monday where I will update the status of Beaker's tests run on Fedora rawhide. Kernel: 3.11.0-0.rc5.git1.1.fc20.x86_64 Test run summary: 882 tests, 14 failures, 26 errors, 3 skips in 2767.7s Causes for failures: - Incompatibility with sqlalchemy-0.8 (https://bugzilla.redhat.com/show_bug.cgi?id=989902) - cracklib-python is broken (https://bugzilla.redhat.com/show_bug.cgi?id=998321) - There are a few other failures/errors which seem to be unrelated to the above, but I am not sure yet. Notes: - selenium-2.35.0 is out which is needed for Beaker's selenium tests to run with recent Firefox versions (I will submit a patch soon to fix this). Best, Amit. -- Amit Saha <http://echorand.me> Infrastructure Engineering and Development Red Hat, Inc.

1 2

Feedback regarding implementing BZ#989924
by Amit Saha 26 Aug '13

26 Aug '13

Regarding implementing [1], the two main changes are: 1. Adding support for a new ks_meta option. For eg. <recipe ks_meta="auth='--useshadow --enablemd5'"> 2. And having support for reading it in the template: +{% if auth %} +auth {{ auth }} +{% endif %} When the ks_meta option is not specified, the generated kickstart doesn't get a 'auth' command entry. Does this look fine? Thanks, Amit. [1] https://bugzilla.redhat.com/show_bug.cgi?id=989924 -- Amit Saha <http://echorand.me> Infrastructure Engineering and Development Red Hat, Inc.

2 5

More conservative removal of implicit job sharing
by Nick Coghlan 26 Aug '13

26 Aug '13

I've been pondering the removal of the old implicit job sharing model from Beaker 0.15, and I'm concerned that it may break existing installations in a way that won't be uncovered until a site upgrades to 0.15 and their users complain about not being able to update jobs any more. At the moment, the only way for installation admins to cope with such complaints is to roll back to 0.14 (a non-trivial exercise). Since we don't track job activity the way we do system activity (as described in bug 995012), installation admins also can't easily check if their users are relying on the feature before they do the upgrade. Accordingly, I think a slight reworking of our approach to this deprecation may be in order: - in 0.15, implicit job sharing remains enabled by default, but can be switched off through a config option - in the subsequent release, it is off by default, but the config option can still be used to turn it back on - only in the release after *that* (and assuming we don't have users complaining about the "off by default" release) do we remove the feature entirely This change is now covered in https://bugzilla.redhat.com/show_bug.cgi?id=1000861, and I'd like to make that a blocker for 0.15. I'd also like to make this our general policy for any future backwards incompatible changes without a simple workaround: - release N adds a config option to turn off the deprecated feature - release N+1 changes the config option to being off by default - release N+2 (at the earliest) actually removes the feature Yes, it's more work for us, but I really want new Beaker releases to be something that users look forward to, rather than something they fear as "What did they break this time?" :) Cheers, Nick. -- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

2 2

Selenium Error and Firefox version
by Amit Saha 19 Aug '13

19 Aug '13

If you are using Firefox 22, you may see: "The error message is: Value does not implement interface Event" error messages. The solution is to downgrade to 21. sigh. Remove Firefox: #yum -y remove firefox xulrunner Get the packages corresponding to 21 for both, and install them. -- Amit Saha <http://echorand.me> Infrastructure Engineering and Development Red Hat, Inc.

2 3

Building Beaker packages on Fedora
by Amit Saha 15 Aug '13

15 Aug '13

For a while, we have been bugged by this Sphinx bug [1], which is fixed now upstream. However, the Fedora sphinx packages are still not updated. The result is that we cannot build Beaker packages on Fedora. When doing it manually, it's OK to patch sphinx and carry on. However, /distribution/beaker/setup will not work because of this and hence any hopes of running 'dogfood' with Fedora will have to be shelved. Is there any interim solution we can adopt without simply waiting for the package to be updated? [1] https://bitbucket.org/birkenfeld/sphinx/commits/447fab1105ec -Amit. -- Amit Saha <http://echorand.me> Infrastructure Engineering and Development Red Hat, Inc.

3 2

Setting up a Beaker instance in Fedora infrastructure
by Nick Coghlan 12 Aug '13

12 Aug '13

I've been chatting to Tim Flink and Toshio Kuratomi here at Flock, and they're amenable to the idea of setting up a small Beaker instance in Fedora infrastructure. Details are still very much to be worked out, but I'm thinking a possible place to start would be for *us* to be the initial users, working towards running Fedora dogfood tasks in that instance rather than (or as well as) doing so inside the firewall. That would let us work out any issues with a non-critical set up, and only start using it for Fedora activities once we had worked out the details (in particular, I suspect we'll have some work to do in the user authentication area). Cheers, Nick. -- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

3 4

Test framework for lshw
by Amit Saha 07 Aug '13

07 Aug '13

As noted in [1], some work needs to be done before we can start writing tests for lshw. Currently, lshw's functionality can be roughly explained as follows: - the file src/lshw.cc examines all the command line arguments - After setting up variables determining the information that is going to be printed, the function scan_system() is called, which is defined in src/core/main.cc - This function, depending on what information has been requested for, calls functions defined in various files - such as cpuinfo.cc for CPU info, mem.cc for memory information and so on which return the requested info. - These files read their data from /proc and /sys and then return the data after filling those in the appropriate data structure. As mentioned in [1], not all reads their data from procfs and sys. For example, those which fetch disk information do it via ioctl() calls. However, as of now, we may ignore the disk related functionality of lshw, since we use libparted for that now. So, we want that instead of reading these data from the live systems, when run as part of the test suite, lshw should ready them from our test data - a snapshot of relevant files from procfs and sysfs. One approach that I can think of is: - Add an extra option to lshw -s specifying the location of the snapshot - When this is set, we can set an environment variable to point to the location of the snapshot. In all the files where the information is read from the file systems, before opening the file, we check for this environment variable, and if it exists, we read the files from there instead. And of course, matching the expected output, etc follows after that. Would be interested in any feedback. Thanks, Amit. [1] https://bugzilla.redhat.com/show_bug.cgi?id=986157 -- Amit Saha <http://echorand.me> Infrastructure Engineering and Development Red Hat, Inc.

4 11

Beaker 0.14.1 released!
by Nick Coghlan 07 Aug '13

07 Aug '13

On behalf of the Beaker development team, I'm pleased to announce that Beaker v0.14.1 is now available from beaker-project.org. In this release, we have finalised the "Enhanced User Groups" design proposal [1], adding the ability for users to nominate "submission delegates": other users that have the ability to submit jobs on their behalf. The primary intended use for this feature is with external automated systems, such as the recently published Jenkins Beaker Builder Plugin [2]. This release also introduces the "Beaker Architecture Guide", starting with a page giving a general overview of Beaker's capabilities: http://beaker-project.org/docs/architecture-guide/capabilities.html Additional details about the above features and smaller changes for this release can be found in the release notes here: http://beaker-project.org/docs/whats-new/release-0.14.html Thank you to all who contributed to this release. Regards, Nick. [1] http://beaker-project.org/dev/proposals/enhanced-user-groups.html [2] https://wiki.jenkins-ci.org/display/JENKINS/Beaker+Builder+Plugin -- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

1 1

Proposal: revised "nag email" system
by Nick Coghlan 07 Aug '13

07 Aug '13

I just filed https://bugzilla.redhat.com/show_bug.cgi?id=994325 with a new proposed design for the nag email system. This may be a good one to squeeze into 0.15, as it should be a fairly isolated change (just the nag_email.py script) and significantly less annoying than the current approach for users with lots of systems reserved that aren't in high demand :) The main changes proposed are to make it: 1. User based, so each user gets at most one email per run 2. Need based, as we only care about systems with "waiting" recipes 3. More helpful, by providing some relevant search links Example email sketch quoted from the RFE: ========= [Beaker] Systems allocated to <username> (<date>) ========= Hi <name>, The following systems have been allocated to you in <Beaker instance FQDN> for more than <X> days and have other recipes queued for execution. Please return them if you are no longer using them. System Reservations Duration Waiting FQDN 23 days 3 recipes host.beakerlab.example.com All systems reserved by you: https://<Beaker instance FQDN>/?systemsearch-0.table=System%2FUser&systemsearch-0.keyvalue=&systemsearch-0.operation=is&systemsearch-0.value=<username> System Loans Duration Waiting FQDN 7 days 1 recipe host2.beakerlab.example.com All systems loaned to you: https://<Beaker instance FQDN>/?systemsearch-0.table=System%2FLoanedTo&systemsearch-0.keyvalue=&systemsearch-0.operation=is&systemsearch-0.value=<username> ========= Cheers, Nick. -- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Beaker-devel August 2013