Bug 1043789 - Create an automated test for a full Beaker provisioning cycle & mulltihost tests
Summary: Create an automated test for a full Beaker provisioning cycle & mulltihost tests
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Beaker
Classification: Retired
Component: tests
Version: develop
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified vote
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-17 08:06 UTC by Nick Coghlan
Modified: 2019-05-22 10:41 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-26 05:04:02 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 883185 0 medium CLOSED Add a set of automated self-tests for Beah 2021-02-22 00:41:40 UTC

Internal Links: 883185

Description Nick Coghlan 2013-12-17 08:06:08 UTC
The virtual Fedora quickstart guide shows that it is possible to create a pure virtual Beaker instance inside a private libvirt network:

https://beaker-project.org/dev/guide/virtual-fedora/

The current Beaker dogfood task *doesn't* perform end-to-end testing of a full Beaker provisioning cycle - it runs the integration test suite on a different version of Beaker, but can't test a new harness release, etc.

This proposal is to create a Beaker task that uses libvirt directly (not Beaker's normal guest provisioning capabilities) to:

1. Create a combined Beaker server/lab controller and a couple of test systems (as described in the virtual Fedora quickstart)
2. Adds the standard tasks and a supported distro tree
3. Manually reserves and returns a system (ensuring ssh access to the provisioned system is supported)
4. Automatically schedules a multihost job and ensures it completes successfully.

Comment 1 Dan Callaghan 2017-07-26 05:04:02 UTC
I am inclined to close this as WONTFIX, because I think that the approach suggested here (create an entire virtualised Beaker lab including test machines and assert that they can be provisioned) would be costly to implement, and does not necessarily give us any better coverage than our current two-sided approach, which is:

* the Python-level unit test + integration test suite in Beaker's source tree, which is run inside dogfood, and exercises all parts of Beaker itself with varying levels of mockery but *no* interaction with real hardware

* the workflow-selftest jobs, including the Jenkins job to invoke it (see bug 954265, bug 1299722), which runs the self-tests to exercise all of Beaker's functionality on *real* hardware with as many different distro/arch combinations as possible


Note You need to log in before you can comment on or make changes to this bug.