Bug 1131388

Summary:	[RFE] Support running tests from inside a container
Product:	[Retired] Beaker	Reporter:	Nick Coghlan <ncoghlan>
Component:	general	Assignee:	Amit Saha <asaha>
Status:	CLOSED CURRENTRELEASE	QA Contact:	tools-bugs <tools-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	0.18	CC:	aigao, asaha, dcallagh, ebaak, jburke, rmancy, xma
Target Milestone:	0.18.3	Keywords:	FutureFeature, Patch
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-10-17 06:21:37 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nick Coghlan 2014-08-19 07:17:15 UTC

Project Atomic uses rpm-ostree to manage the host environment, so we can't install arbitrary additional packages. The Atomic host environment is also not a reasonable place to run tasks, as a lot packages simply won't be present - the Atomic host component provides the bare minimum of infrastructure needed to run containers, so a lot of otherwise expected OS components are missing.

Amit's patch at http://gerrit.beaker-project.org/#/c/3199 provides a reasonable starting point towards enabling this.

My suggestion is that we aim to get something basic released in the 0.18 time frame (such as Amit's patch, modified to avoid touching the public internet), and then iterate from there.

The harness repo URL should be injected by the server, rather than hardcoded into the template snippet.

For the initial iteration, only the Docker image registry URL needs to be configurable. The base image and whether or not the container is privileged will need to be configurable eventually, but that doesn't need to be in the initial iteration.

Comment 1 Amit Saha 2014-09-12 05:33:55 UTC

http://gerrit.beaker-project.org/#/c/3199/3

What it does:

- Run tests inside a Fedora 20 docker container
- Allows specifying a docker registry. If not specified, defaults to using the public registry
- Uses restraint test harness (allows specifying the restraint repo)

What it doesn't allow:

- Tests cannot restart the host (trivial to add)
- tests cannot spawn other containers (easy to add)
- Test cannot specify the distro in which to execute the test (doable fairly easily once we have the restraint repos setup such that we can just specify a dsitro variable)

Comment 2 Amit Saha 2014-09-15 03:28:31 UTC

(In reply to Amit Saha from comment #1)
> http://gerrit.beaker-project.org/#/c/3199/3

> What it doesn't allow:
> 
> - Tests cannot restart the host (trivial to add)
> - tests cannot spawn other containers (easy to add)
> - Test cannot specify the distro in which to execute the test (doable fairly
> easily once we have the restraint repos setup such that we can just specify
> a dsitro variable)

Instead of hardcoding the distro which the container runs and hence the test harness runs in, I now default to the distro image used in <distroRequires>. So, for example, if the distro is Fedora20, I use the docker image as Fedora with tag 20. Two additional ks_meta variables, "docker_image" and "docker_tag" can be used to specify a different distro/tag. 

However, the restraint repo URL *needs* to be specified correctly, since it defaults to the Fedora 20 URL. 

For eg:

ks_meta="contained_harness docker_registry=docker-registry.mysys.com/ docker_image=centos6 docker_tag=latest restraint_repo=https://bpeck.fedorapeople.org/restraint/el6.repo selinux=--disabled"

will run the test harness in CentOS6.

Comment 3 Amit Saha 2014-10-02 02:32:48 UTC

> - Test cannot specify the distro in which to execute the test (doable fairly
> easily once we have the restraint repos setup such that we can just specify
> a dsitro variable)


As explained by https://git.beaker-project.org/cgit/beaker/diff/documentation/user-guide/customizing-installation.rst?h=develop, the merged patch allows selecting any arbitrary docker image for the harness with the mentioned restrictions.

Comment 4 Nick Coghlan 2014-10-02 05:22:03 UTC

Where are we at with getting restraint included in the default harness repos?

That would address the issue with needed to specify the correct restraint repo.

Comment 7 Dan Callaghan 2014-10-16 05:35:17 UTC

Amit has back-ported this to release-0.18 for the 0.18.3 release.

Comment 10 Dan Callaghan 2014-10-17 06:21:37 UTC

Beaker 0.18.3 has been released.