Beaker-devel November 2013

beaker-devel@lists.fedorahosted.org

11 participants
24 discussions

Adding resource management to beaker
by Bill Peck 21 Oct '14

21 Oct '14

Hello Beaker, One of the jobs we run uses shared storage. For example: HostA with Driver1 HostB with Driver2 HostC with Driver3 All connected to StorageX. We can't run the test on more than one host at a time since it would conflict. Being able to specify the following in the job xml is the goal: <recipeSet> <recipe/>  <resource/>  </recipeSet> <recipeSet> <recipe/>  <resource/>  </recipeSet> <recipeSet> <recipe/>  <resource/>  </recipeSet> I know there is a resource type for recipe but this doesn't seem like a good solution. I did try an experiment where I created StorageX host in beaker with no power control and scheduled three recipesets like above. But this hack won't work because a watchdog with a NULL expire time is set and that means it will sit there forever. Even if it did work, maybe if we created a dummy power type, we would still end up with an abort. I don't think it would take much work to support this type of multi-host/resource requirement. Right now we have the following model Object Recipe, which has the following attributes: distro_tree, resource, rendered_kickstart, watchdog, systems, dyn_systems, tasks, dyn_tasks, tags, repos, rpms, logs, custom_packages, ks_appends Object MachineRecipe which inherits from Recipe, and adds a guests attribute. Object GuestRecipe which inherits from Recipe. A ResourceRecipe object wouldn't need most of these attributes, probably just the following: resource, systems, and dyn_systems. (no watchdog, just return when recipeSet completes or aborts) And resource currently maps to a RecipeResource which can be one of the following: SystemResource VirtResource GuestResource I think adding another Object here would make sense, but the term Resource is overused and its a little confusing right now. If done correctly we could re-use the filtering code in needproperty, but I think the only things we could search on for resources would be the following: Name, lab_controller, and key_values? (storing how these shared resources are connected would be another option I suppose, but maybe too complicated for a first implementation?) I'm sure there are other things to consider, we could support setting up and tearing down shared resources (almost like a power on/off command). I want to be mindful of things like that but I don't want to be paralysed with what if's and never get anything done. I know you guys have been working hard on the groups features and want to re-do the scheduler as well. Maybe this would be something for after the scheduler re-write? I don't see any mention of this on the roadmap [1] (although the roadmap is quite full already!). In any event, I'm interested in hearing your ideas and feedback. Thanks! 1 - http://beaker-project.org/dev/tech-roadmap.html

2 2

External tasks proposal up on beaker-project.org
by Nick Coghlan 05 Feb '14

05 Feb '14

I decided it made more sense to publish Bill's external tasks library on beaker-project.org and start a thread here, rather than continue to conduct the high level design discussions in the Gerrit review. Firstly, I like the idea of "fetch" and "rpm" nodes in the task XML. The proposal should be more explicit about the fact that the RPM node is only present in the recipe XML when it is retrieved through the stable harness API, and not in other cases (such as when cloning a job). I *don't* like the way the proposal refers to *removing* the task library. The task library isn't going anywhere, we're just providing a way to bypass it when doing so makes sense. The task library is still an incredibly convenient way to publish utilities like the standard tasks (http://beaker-project.org/docs/user-guide/beaker-provided-tasks.html) and potentially future higher level utilities like properly configured KDC, LDAP and qpid servers. Finally, I'd prefer it if the proposal was backed by a core "/distribution/gitfetch" task, together with the ability to flag a task in the task library as "external". When a task was flagged as external, then Beaker would *require* that a "fetch" element exist, and would display that URL when appropriate. Given the UI issues in the Beaker 0.15 upgrade, I'm concerned about breaking the fundamental assumption of every task being associated with an entry in the task library. By using an "external" flag and an implied task name (instead of leaving the task library reference NULL), it changes the failure mode from failing to handle an unexpected NULL or None value to display the task name as usual rather than the desired URL details. Regards, Nick. -- Nick Coghlan Red Hat Hosted & Shared Services Software Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

2 1

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

New sub-command to list access policy for a system
by Amit Saha 01 Dec '13

01 Dec '13

I noticed that there is no sub-command to list the existing policy for a system, so tried writing one [1]. My primary objective is to of course having it as a sub-command, unless there was another reason other than time that it wasn't added earlier. The second objective is to use it as the second example in our developer guide to show how you expose controller methods and write a client to access it. Example usage: # bkr policy-list --system beaker-test-vm1 --hub http://localhost/bkr --username admin --password foobar { "rules": [ { "everybody": true, "permission": "control_system", "group": null, "id": 1, "user": null }, { "everybody": true, "permission": "reserve", "group": null, "id": 4, "user": null } ], "possible_permissions": [ { "value": "edit_policy", . .. . .. The authentication bit is not required I suspect. [1] http://paste.fedoraproject.org/41757/13800067/ Thoughts and suggestions welcome. Best, Amit. -- Amit Saha <http://echorand.me> Infrastructure Engineering and Development Red Hat, Inc.

3 16

Beaker 0.14.4 released
by Dan Callaghan 29 Nov '13

29 Nov '13

On behalf of the Beaker development team, I'm pleased to announce that Beaker 0.14.4 is now available from beaker-project.org [1]. This release fixes a regression introduced in Beaker 0.14.3 which affects scheduling of multi-host recipe sets in Beaker installations with more than one large lab with high contention [2]. A number of other minor fixes, particularly related to x86_64 EFI systems, are also included. Refer to the updated release notes [3] for a complete list of bug fixes. [1] http://beaker-project.org/releases/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1033032 [3] http://beaker-project.org/docs/whats-new/release-0.14.html#beaker-0-14-4 -- Dan Callaghan <dcallagh(a)redhat.com> Software Engineer, Hosted & Shared Services Red Hat, Inc.

1 0

Authentication for non-Kerberos Beaker instances
by Nick Coghlan 28 Nov '13

28 Nov '13

Unless/until we fix the storage of passwords for Beaker's native password-based auth, I'd like to explicitly warn people away from relying on that configuration in the docs. However, our own solution to that problem is to let mod_auth_kerb do the heavy lifting, which isn't going to be applicable to something like beaker.fedoraproject.org Has anyone tried to use mod_auth_oauth at all? I'm wondering if that may be a more upstream-friendly alternative that still avoids relying on the currently-not-suitable-for-production-use-on-the-big-bad-internet password based auth. Cheers, Nick. -- Nick Coghlan Red Hat Infrastructure Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

3 2

Changing the headline on the Beaker home page?
by Nick Coghlan 26 Nov '13

26 Nov '13

The headline on beaker-project.org currently describes Beaker thus: "Beaker is open-source software for managing and automating labs of test computers." While technically accurate, I don't think it adequately differentiates Beaker from pure inventory management systems like openDCIM and pure test automation systems like Jenkins, STAF/STAX and autotest. The following is too long for the headline, but is the "elevator pitch" I've been using lately to described Beaker's scope in one sentence: "Beaker provides shared access to a wide range of hardware configurations for both manual failure investigation and automated compatibility testing." The capability overview in the architecture guide (http://beaker-project.org/docs/architecture-guide/capabilities.html) currently starts with: "Beaker is a full stack software and hardware integration testing system, with the ability to manage a globally distributed network of test labs." So, here's my initial proposal for a new headline: "Beaker provides global shared access to diverse collections of test systems." Thoughts? 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

Questions regarding DHCP/DNS requirements for IPv6 support
by Nick Coghlan 26 Nov '13

26 Nov '13

This is mostly aimed at Amit (since he's been looking into this lately), but I've been pondering exactly what is needed from an environmental point of view to enable testing of IPv6-only systems directly within Beaker. My current understanding of the supporting config Beaker needs to support this is below, so my general questions are: a) did I miss anything?; and b) is anything I have listed wrong? * Main beaker server - needs both A and AAAA records assigned in DNS - needs to serve the task library yum repo over both IPv4 and IPv6 * Lab controllers - need both A and AAAA records assigned in DNS - beaker-proxy needs to listen on both IPv4 and IPv6 (implemented in 0.14.4) - TFTP server needs to be serving over both IPv4 and IPv6 * NTP servers - need to be accessible over both IPv4 and IPv6 * Test systems - need both A and AAAA records to be assigned by DHCP - need to be given both IPv4 and IPv6 addresses for the NTP servers As far as I am aware, we don't do "push" communications from the LC or the main server to the test systems, so we don't care if the test system only has IPv4 or IPv6 enabled. With this model, the following test scenarios should all be possible directly within Beaker rather than requiring external resources: * IPv4 only - system is provisioned with an IPv4 only OS, or explicitly has IPv6 support turned off - connects to LC, NTP and main server over IPv4 - users must ssh in over IPv4 * IPv6 only - system explicitly has IPv6 support turned off - connects to LC, NTP and main server over IPv6 - users must ssh in over IPv6 - implicitly tests IPv6 only client -> IPv4 or IPv6 server handling - to test interaction with IPv6 only server, use a multi-host test * IPv4 or IPv6 - system has both IPv4 and IPv6 support enabled - connects to LC, NTP and main server over IPv4 or IPv6 (OS/client app dependent) - users can ssh in over either IPv4 or IPv6 (OS/client app dependent) - implicitly tests IPv4 or IPv6 client -> IPv4 or IPv6 server handling - to test interaction with IPv4 only server, use a multi-host test - to test interaction with IPv6 only server, use a multi-host test Cheers, Nick. -- Nick Coghlan Red Hat Hosted & Shared Services Software Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

4 5

Adding "server" and "core tasks" components to Bugzilla
by Nick Coghlan 24 Nov '13

24 Nov '13

We've previously discussed revamping the Beaker component list in Bugzilla, but never come up with anything that seemed worth the hassle. However, looking at it from the perspective of "handling bugs that don't currently have a good home", I think two new components would cover us. 1. "server" This component would be used for all server-only bugs that aren't specific to the web UI, the scheduler, native reports. Bugs for kickstart generation, permissions issues, data model cleanups, server-only utility scripts would all live here. 2. "core tasks" This would cover any bugs related to the standard tasks that don't have a dedicated component (i.e. anything that now lives in beaker-core-tasks, other than the inventory task). The "inventory" component would cover both the inventory task and beaker-system-scan. So the overall structure would be: general Doc server scheduler web UI reports lab controller qpid (since distro expiry is our only current messaging support) command line test harness (beah and beah-ipv6) core tasks (beaker-core-tasks) inventory (includes beaker-system-scan) tests (includes beaker-meta-tasks) Thoughts? Cheers, Nick. -- Nick Coghlan Red Hat Hosted & Shared Services Software Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

2 2

Possible config file compatibility issue for SQLAlchemy 0.9
by Nick Coghlan 24 Nov '13

24 Nov '13

SQL Alchemy 0.9 is switching the engine URL handling to comply with RFC 1738: http://docs.sqlalchemy.org/en/rel_0_9/changelog/migration_09.html#the-passw… I don't think that change will impact Beaker directly, but it could potentially affect the required spelling of affected passwords in configuration files depending on the version of SQL Alchemy in use. Cheers, Nick. -- Nick Coghlan Red Hat Hosted & Shared Services Software Engineering & Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/)

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Beaker-devel November 2013