Beaker-devel November 2013

beaker-devel@lists.fedorahosted.org

11 participants
24 discussions

Beaker git repo restructuring
by Nick Coghlan 22 Nov '13

22 Nov '13

Over the last few months, it has become clear that as we changed the branch lifecycle for the main Beaker repo, several of the things that had previously lived in that repo no longer belonged there. To that end, Dan has now broken out three new git repos on beaker-project.org: beaker-core-tasks: these are the tasks needed for various Beaker features /distribution/install /distribution/inventory /distribution/reservesys /distribution/updateDistro This will also be the eventual home for the guest recipe tasks once their open sourced properly. beaker-meta-tasks: these are Beaker's self testing tasks, and any other tasks we create to figure out correct settings for Beaker /distribution/beaker/Sanity/bz880440-fqdn-self-reporting /distribution/beaker/Sanity/sync-set_block-tests /distribution/beaker/custom_kickstart /distribution/beaker/dogfood /distribution/beaker/fake_systems /dsitribution/beaker/import /dsitribution/beaker/setup Finally, beaker-administrivia is the home for some utility scripts we use to keep Bugzilla, Gerrit and the core team's internal task tracking in sync (these initially lived under the Misc directory in the main repo, but having them vary by Beaker version doesn't make any sense). There's still some more cleanup to be done next week (setting up Gerrit notifications, updating the developer guide), but the bulk of this change is now complete. We're also working on decoupling the release cycles for beah and the standard tasks from the main Beaker release cadence. Since they're much easier to update than Beaker itself, there's a potential opportunity for faster turnaround times for fixes if we can streamline their release processes. Cheers, Nick. -- Nick Coghlan Red Hat Hosted & Shared Services Software Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

1 0

Draft development lifecycle guide
by Nick Coghlan 20 Nov '13

20 Nov '13

As a key step in making the core development process less opaque to folks outside the Red Hat firewall (and to formalise some of the changes we made following the 0.15 release), I've put a draft development lifecycle guide up on Gerrit: http://gerrit.beaker-project.org/#/c/2520 Comments here or on the review welcome :) Cheers, Nick. -- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

1 0

GitHub releases for peripheral/related projects
by Amit Saha 19 Nov '13

19 Nov '13

While thinking of how to go about writing Beah's release notes, it came to my mind that why don't we use GitHub release feature for that? [1] What I have in mind is once we are done with the tagging, GitHub has a zip/.tar.gz ready. We could use GitHub's Web UI to do the entire release process and have a link from the beah docs. I have zero experience with using this GitHub feature. They also have an API. So perhaps, we can do all of it with a script. Thoughts? If this sounds encouraging, I could give it a shot and also we can adopt it for our other projects. [1] https://github.com/blog/1547-release-your-software Best, Amit. -- Amit Saha <http://echorand.me> Infrastructure Engineering and Development Red Hat, Inc.

3 7

Beaker 0.15.x missing from beaker-project.org RHEL repos
by Nick Coghlan 17 Nov '13

17 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Looks like even though we got the 0.15.1 RPM upload issues sorted out last week, the metadata for the RedHatEnterpriseLinux repos on beaker-project.org still shows 0.14.2 as the latest version :( The Fedora repos appear fine, almost certainly due to the fact that those are generated differently. Cheers, Nick. - -------- Original Message -------- Subject: Re: Requesting/managing upgrades to beaker.fedoraproject.org Date: Tue, 05 Nov 2013 12:50:09 +1000 From: Nick Coghlan <ncoghlan(a)redhat.com> Organization: Red Hat Asia-Pacific To: qa-devel(a)lists.fedoraproject.org On 11/05/2013 07:15 AM, Tim Flink wrote: > On Fri, 01 Nov 2013 18:43:32 +1000 Nick Coghlan > <ncoghlan(a)redhat.com> wrote: > > On 11/01/2013 05:23 PM, Tim Flink wrote: >>>> I'm fine with either direction for now. My hesitation on >>>> getting started with 1) is that having a beaker installation >>>> is still an evaluation for us. I have a hard time seeing >>>> things not working out but I also don't pretend to be >>>> clarvoyant :) >>>> >>>> If you guys are fine with putting work into something that >>>> will probably change (see comment below about ansible), I >>>> can get the ball rolling to separate the ACL for the beaker >>>> server and get you all the access you need. Otherwise, I can >>>> just apply the updates myself. Let me know if you all have a >>>> preference on which route to take right now. > > If you're happy to do the update, I think it makes more sense for > you to handle this one. The beaker-project.org repos should have > 0.15.1 available now, and the upgrade instructions are at > http://beaker-project.org/docs/whats-new/upgrade-0.15.html > >> I tried upgrading today and I don't think that any el6 rpms are >> available for 0.15 in the yum repos on beaker-project.org. We had some weirdness with the RPM publication due to the fact 0.15.1 was an upstream-only release, but I thought we resolved that last week. However, even though we sorted out the RPM upload issues, it appears only the Fedora repos have been generated correctly - the metadata for the various RHEL repos looks like it is still missing the 0.15.x releases :( We'll dig into it. Cheers, Nick. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSeF/sAAoJEHEkJo9fMO/LVXYH/jszQ+z0OJVDAs1YCC0QNHLu p7MK67s0KKzs5KTW5G2EuD6/se99YmJR6dKvEFg3h9PispOMl1LTRb+5ZVYS2HKC erBuD3vQTh4E/mMQwWPZmnUhIfdycZOwuAWWphdMhRqgY78xC2wSqujYZSNgWGGP MvEshVfF+i6+yh24njEs56+2gTFluiQ/mUQ6IqMbc0B9QMglSF7Y1gH2zGKEwrmw yDlFUWe/NI5/6YRTn8/D+kW5U03beB+fKF+xKrgiubTYes4G4dhetFFxsVl4eYFB 0x1NLTxHKnvWQUDKWU/fgDQkFbLXzohychGHOhougBjaZybCGqs2SvZ7mSsfqf4= =lykB -----END PGP SIGNATURE-----

4 7

Beaker 0.14.3 released!
by Raymond Mancy 14 Nov '13

14 Nov '13

On behalf of the Beaker development team, I'm pleased to announce that Beaker v0.14.3 is now available from beaker-project.org [1]. The main change with this release is the addition of extra checks to help avoid the issue of guest recipes being scheduled (and subsequently aborted) on labs that do not contain the distro they require. A more thorough overview of the changes can be found in the updated release notes [2], and in the changelog[3]. Regards, Raymond. [1] http://beaker-project.org/releases/ [2] http://beaker-project.org/docs/whats-new/release-0.14.html#beaker-0-14-3 [3] http://beaker-project.org/releases/beaker-0.14.3-ChangeLog

1 0

Remove bkr.server.model.Locked?
by Nick Coghlan 14 Nov '13

14 Nov '13

Reviewing the DB schema, Ray noticed a puzzling "locked" table where he didn't know what it was for. I checked, and it corresponds to a Locked model element in the source, but we don't actually appear to refer to it anywhere. Can anyone think of a reason we shouldn't just delete it in 0.16 as a legacy data model element that wasn't properly removed when it was no longer needed? Cheers, Nick. -- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

2 1

Testing changes to beaker-system-scan
by Amit Saha 13 Nov '13

13 Nov '13

Dan pointed out during the review of [1], that it would be good to verify the changes across all supported architectures by running an inventory job on each. So, to have something like 'patchbot' which runs the dogfood jobs, we will need an ability to checkout a patch from Gerrit and build beaker-system-scan RPMs and use those instead of the ones in the repository. This patch [2] aims to add this support. [1] http://gerrit.beaker-project.org/#/c/2481/ [2] http://gerrit.beaker-project.org/#/c/2490/1 Comments/suggestions? Best, Amit. -- Amit Saha <http://echorand.me> Infrastructure Engineering and Development Red Hat, Inc.

1 0

Related projects page on beaker-project.org
by Amit Saha 10 Nov '13

10 Nov '13

Recently, Beah's docs were reorganized a bit [1] so that we could have a dedicated place for them to live. Currently, they live here [2]. This is part of a "bigger" plan to maintain a "Related Projects" page which is linked from Beaker's home page. This page will contain references to spin-off projects such as Beah - with dedicated documentation and release history/notes, etc. I attempted to do this here [3], but I am not sure if that is the best way to do it. Suggestions/thoughts welcome. [1] http://gerrit.beaker-project.org/#/c/2431/ [2] http://beaker-project.org/docs-beah/ [3] http://gerrit.beaker-project.org/#/c/2432/ Best, Amit. -- Amit Saha <http://echorand.me> Infrastructure Engineering and Development Red Hat, Inc.

2 2

Continuous integration for beah and rhts patches?
by Nick Coghlan 10 Nov '13

10 Nov '13

Since I've been reviewing and working on a couple of beah and rhts changes recently, it occurred to me it would be highly desirable to have some kind of CI for harness related updates. However, I also can't see a straightforward way to make that happen :( Cheers, Nick. -- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

2 1

Separate git repo and release process for standard tasks
by Nick Coghlan 10 Nov '13

10 Nov '13

Amit has been looking at creating separate documentation for the default test harness, and that will eventually lead to a separate release process for the harness as well (allowing harness updates to be more easily published without publishing a new Beaker release). This becomes more significant as we start more actively supporting multiple Beaker installations which may be running different versions of Beaker, and also as we start maintaining multiple active branches in the Beaker repo (at the moment, that's two maintenance branches and the develop branch, although we expect the normal case to just be one maintenance branch and the develop branch). A related problem exists with the Tasks directory, especially as we start looking to publish more of the current Red-Hat-internal-for-no-good-reason utility tasks like /distribution/virt/install, /distribution/virt/start and /distribution/command. The explicit "Library task" support in Beaker wizard discussed in https://bugzilla.redhat.com/show_bug.cgi?id=910750 is also relevant, as we're likely to end up wanting to publish some library tasks as open source, and we're also going to want a home for the "reference tasks" described in https://bugzilla.redhat.com/show_bug.cgi?id=961239 This suggests to me that over the next few weeks or months, we should look at moving the existing open source tasks out of the main Beaker repo into a new "beaker-tasks" repo, and structure the latter in a way that makes it possible to install the "latest and greatest" Beaker tasks into your instance by doing something like: $ sudo yum update beaker-tasks-core beaker-tasks-reference beaker-tasks-library $ bkr update-standard-tasks core reference library rather than the current: $ wget -r -np -nc https://beaker-project.org/tasks/ $ for f in `ls *.rpm` > do > bkr task-add --hub=http://beaker-server-lc.beaker/bkr \ > --username=<USER> --password=<PASSWORD> $f > done 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 November 2013