Bug 747766

Summary:	RFE : Schedule a test with no provisioning.
Product:	[Retired] Beaker	Reporter:	Vasiliy Sharapov <vsharapo>
Component:	web UI	Assignee:	Raymond Mancy <rmancy>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	0.7	CC:	bpeck, dcallagh, ebaak, mcsontos, rmancy, stl
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-10-02 06:04:09 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Vasiliy Sharapov 2011-10-21 00:41:32 UTC

The use case:
Schedule a test that provisions and runs some unreliable tests (wireless in our case)
Some test fails, we suspect it could have been the environment (lots of noise in the wireless tent)
We want to re-try the test that failed.

The problem:
We have to wait 35 minutes to re-provision the machine to run a 2 minute test when we know very well that the machine hasn't changed since then and doesn't need to be wiped to be able to run the test.

The kludge:
If a test is known to be unreliable we make a custom run where it's run many times repeatedly and we can see if it passed or failed.

The dream:
Removing the provision-associated XML will keep the test valid and it will run without provisioning.

Comment 1 Dan Callaghan 2012-10-02 06:04:09 UTC

Provisioning the system at the start of each recipe is an integral part of how Beaker works. It guarantees a known starting state for the tasks in the recipe. In that sense, it is a feature, not a bug :-) On a more serious note, there is no practical way to support this (running a recipe without provisioning the system first) without completely re-architecting how Beaker works.

The problem you have is a very common one. The typical solution is to ensure your job has /distribution/reservesys as the last task (perhaps with RESERVE_IF_FAIL=1 so the reservation only happens if the recipe fails) and then if something goes wrong, log in to the box and investigate. Your investigation can of course include modifying some things and then running the task again:

    cd /mnt/tests/distribution/something
    make run