Future directions for the Beaker test harness
by Nick Coghlan
A few weeks back, Amit put together a proof of concept for running the
test harness in a container, rather than directly on the host
(http://gerrit.beaker-project.org/#/c/3199).
That proof of concept relies on restraint, the new reference harness,
that is intended to eventually replace beah
(https://beaker-project.org/dev/proposals/reference-harness.html)
At the same time, I don't think restraint is currently getting the level
of review and testing that it needs to mature into a plausible
replacement for beah as the default harness.
I think Amit's proposed patch provides a possible way forward:
1. Accept the initial approach where restraint is the *only* supported
harness when running inside a container. Specifying both
"contained_harness" and "harness" as ks_meta variables should be an
error at this point (side note: 'harness' should also be documented
along with all the other ks_meta variables, with a link to
https://beaker-project.org/docs/alternative-harnesses/).
2. Recommend publishing both beah *and* restraint in the harness repos
for Beaker installations. This will not only make restraint available
for container based testing, but also make it readily available via
"harness=restraint" for normal testing, without needing to add a custom
repo definition.
3. Once we have container based testing working reliably with restraint,
drop the restriction against using alternative harnesses in containers.
The priority at the moment though is to get something working that can
run on an Atomic Host, and still provide a relatively normal execution
environment for the executed tasks. Supporting alternative harnesses
*inside* containers is a nice-to-have that can wait until later - by
flatly disallowing it, we ensure we don't have to spend any time working
on container related issues that don't impact restraint. For the initial
iteration, we can also ignore the question of choosing the base image
used to run the harness, as well as being able to start and stop other
containers on the host.
I've filed an RFE for 0.18 on that basis:
https://bugzilla.redhat.com/show_bug.cgi?id=1131388
As part of this, we may also want to move restraint from Bill's personal
account on GitHub to the main Beaker project account, but I don't think
that's particularly urgent at this point.
Regards,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
HSS Provisioning Architect
5 years, 6 months
provision 2 machines in beaker on the same subnet
by Shang Gao
Hi all,
I was trying to provision 2 machines in beaker for kvm migration, they need to be on the same subnet, can we set up it in follow section of Job XML? Thanks!
<recipeSet priority="Normal">
<recipe ... >
...
<hostRequires>
<and>
<arch op="=" value="x86_64"/>
<key_value key="MEMORY" op=">" value="2048"/>
<key_value key="DISK" op=">" value="30000"/>
</and>
<system_type value="Machine"/>
</hostRequires>
</recipe>
<recipe ... >
<hostRequires>
<and>
<arch op="=" value="x86_64"/>
<key_value key="MEMORY" op=">" value="2048"/>
<key_value key="DISK" op=">" value="30000"/>
</and>
<system_type value="Machine"/>
</hostRequires>
</recipe>
</recipeSet>
Best Regards,
Shang Gao
8 years, 3 months
Using Beaker to test a mass rebuild of Fedora Python packages against Python 3.5
by Nick Coghlan
With Python 3.5 in beta upstream, I'd like to create a Beaker recipe that:
1. Rebuilds the Fedora Python RPMs using the upstream Python 3.5 beta
tarball rather than the stable 3.4 release
2. Queries the Fedora repos to get the list of all packages with a build
or runtime requirement on Python 3
3. Uses
https://beaker-project.org/docs-develop/user-guide/beaker-provided-tasks....
to rebuild all the packages from 2 against the Python 3.5 beta RPM from 1
This idea pushes the limits of my current rpm/yum/dnf foo though, so I
figured I'd ask for advice here before I started hacking away at the
problem :)
Cheers,
Nick.
--
Nick Coghlan
Red Hat PnT Operations
DevOps Enablement, Brisbane
Software Development Workflow Designer & Process Architect
8 years, 3 months
Performance testing of the DB queries
by Amit Saha
Most recently this bug [1] made me think if there is a way to catch these sort
of problems during testing rather then in production. I think what we lack really
is the amount of data that our application has to query in production is magnitudes
bigger than during our integration tests or even our development environment.
May be we should look to do that as part of our test suite?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1226076
--
Amit Saha <http://echorand.me>
PnT DevOps - Developer
Red Hat, Inc.
8 years, 3 months
[rhts][PATCH] s/sepcify/specify/
by Jan Pokorný
Signed-off-by: Jan Pokorný <jpokorny(a)redhat.com>
---
bin/rhts-abort | 2 +-
bin/rhts-recipe-sync-block | 6 +++---
bin/rhts-recipe-sync-set | 8 ++++----
bin/rhts-submit-log | 4 ++--
bin/rhts-sync-block | 8 ++++----
bin/rhts-sync-set | 10 +++++-----
6 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/bin/rhts-abort b/bin/rhts-abort
index 8c3f44b..cea6efa 100755
--- a/bin/rhts-abort
+++ b/bin/rhts-abort
@@ -107,7 +107,7 @@ def main():
recipeid = val
if not type:
- print "You must sepcify a type with the -t flag"
+ print "You must specify a type with the -t flag"
sys.exit(1)
if not result_server:
diff --git a/bin/rhts-recipe-sync-block b/bin/rhts-recipe-sync-block
index 175b625..2d882a4 100755
--- a/bin/rhts-recipe-sync-block
+++ b/bin/rhts-recipe-sync-block
@@ -49,10 +49,10 @@ def sync_block(states,machines,any_machine,timeout):
result_server = "http://%s/cgi-bin/rhts/scheduler_xmlrpc.cgi" % result_server
if not result_server:
- raise Exception, "You must sepcify the result server with the -R switch"
+ raise Exception, "You must specify the result server with the -R switch"
if not recipesetid:
- raise Exception, "You must sepcify the recipesetid with the -r switch"
+ raise Exception, "You must specify the recipesetid with the -r switch"
client = xmlrpclib.Server(result_server)
curr_states = []
@@ -125,7 +125,7 @@ def main():
return -1
if not states:
- raise Exception, "You must sepcify a state with the -s switch"
+ raise Exception, "You must specify a state with the -s switch"
if not result_server:
sys.stderr.write("result_server not set, assuming developer mode.\n")
diff --git a/bin/rhts-recipe-sync-set b/bin/rhts-recipe-sync-set
index 406cc00..2662db6 100755
--- a/bin/rhts-recipe-sync-set
+++ b/bin/rhts-recipe-sync-set
@@ -40,15 +40,15 @@ def sync_set(state):
result_server = "http://%s/cgi-bin/rhts/scheduler_xmlrpc.cgi" % result_server
if not result_server:
- print "You must sepcify the result server with the -R switch"
+ print "You must specify the result server with the -R switch"
sys.exit(1)
if not hostname:
- print "You must sepcify the hostname with the -m switch"
+ print "You must specify the hostname with the -m switch"
sys.exit(1)
if not recipesetid:
- print "You must sepcify the recipesetid with the -r switch"
+ print "You must specify the recipesetid with the -r switch"
sys.exit(1)
client = xmlrpclib.Server(result_server)
@@ -97,7 +97,7 @@ def main():
recipesetid = val
if not state:
- print "You must sepcify a state with the -s switch"
+ print "You must specify a state with the -s switch"
sys.exit(1)
if not result_server:
diff --git a/bin/rhts-submit-log b/bin/rhts-submit-log
index 5b9f2bd..a2014dc 100755
--- a/bin/rhts-submit-log
+++ b/bin/rhts-submit-log
@@ -73,7 +73,7 @@ def main():
assert start >= 0, "start must be greater or equall zero."
if not logname:
- print "You must sepcify a logfile with the -l switch"
+ print "You must specify a logfile with the -l switch"
sys.exit(1)
if not result_server:
@@ -82,7 +82,7 @@ def main():
sys.exit(0)
else:
if not recipetestid:
- print "You must sepcify a recipetestid with the -T switch"
+ print "You must specify a recipetestid with the -T switch"
sys.exit(1)
report_log(recipetestid, logname, start=start)
diff --git a/bin/rhts-sync-block b/bin/rhts-sync-block
index c304ca3..95b494a 100755
--- a/bin/rhts-sync-block
+++ b/bin/rhts-sync-block
@@ -55,13 +55,13 @@ def sync_block(states,machines,any_machine,timeout):
result_server = "http://%s/cgi-bin/rhts/scheduler_xmlrpc.cgi" % result_server
if not result_server:
- raise Exception, "You must sepcify the result server with the -R switch"
+ raise Exception, "You must specify the result server with the -R switch"
if not recipesetid:
- raise Exception, "You must sepcify the recipesetid with the -r switch"
+ raise Exception, "You must specify the recipesetid with the -r switch"
if not testorder:
- raise Exception, "You must sepcify the testorder with the -t switch"
+ raise Exception, "You must specify the testorder with the -t switch"
client = xmlrpclib.Server(result_server)
curr_states = []
@@ -138,7 +138,7 @@ def main():
return -1
if not states:
- raise Exception, "You must sepcify a state with the -s switch"
+ raise Exception, "You must specify a state with the -s switch"
if not result_server:
sys.stderr.write("result_server not set, assuming developer mode.\n")
diff --git a/bin/rhts-sync-set b/bin/rhts-sync-set
index 6a5351b..76b9814 100755
--- a/bin/rhts-sync-set
+++ b/bin/rhts-sync-set
@@ -41,19 +41,19 @@ def sync_set(state):
result_server = "http://%s/cgi-bin/rhts/scheduler_xmlrpc.cgi" % result_server
if not result_server:
- print "You must sepcify the result server with the -R switch"
+ print "You must specify the result server with the -R switch"
sys.exit(1)
if not hostname:
- print "You must sepcify the hostname with the -m switch"
+ print "You must specify the hostname with the -m switch"
sys.exit(1)
if not recipesetid:
- print "You must sepcify the recipesetid with the -r switch"
+ print "You must specify the recipesetid with the -r switch"
sys.exit(1)
if not testorder:
- print "You must sepcify the testorder with the -t switch"
+ print "You must specify the testorder with the -t switch"
sys.exit(1)
client = xmlrpclib.Server(result_server)
while True:
@@ -105,7 +105,7 @@ def main():
testorder = val
if not state:
- print "You must sepcify a state with the -s switch"
+ print "You must specify a state with the -s switch"
sys.exit(1)
if not result_server:
--
2.4.2
8 years, 3 months
Simplify inventorying systems in Beaker
by Amit Saha
Hi all,
As part of implementing https://bugzilla.redhat.com/show_bug.cgi?id=846185 and
https://bugzilla.redhat.com/show_bug.cgi?id=1121462, I was thinking that the best
user experience would be if we ask nothing of the user. They need to just click
on a system's "Update Inventory" button or run the "bkr update-inventory <fqdn>" command
to update the inventory data for the system.
So, the key step is to figure out which distro to use. RHEL6/CentOS6 would cover most
of the hardware, but there may be exceptions for older/newer hardware archs. So, here is
what I am thinking:
1. Start with RHEL6/CentOS6, and check if the system is compatible with it. If yes, go to step 4,
else go to step 2.
2. Is the system compatible with RHEL7/CentOS7? If yes, go to step 4, else go to step 3.
3. Is the system compatible with RHEL5/CentOS5? If yes, go to step 4, else error out.
4. Submit a job with the chosen distro and /distribution/install and /distribution/inventory tasks.
(The job will use the <hostRequires force = .. /> element so that all non-removed systems can be inventoried
as long as the job owner has the sufficient rights on the system)
One immediate drawback of this is using hard coded distro names above.
Another idea I can think of is have a system level ksmeta variable defined such as "inventory_distro=MyOSMajor"
and use that. But that is asking of system owners/beaker admins to have to do that explicitly.
It would also vastly simplify the implementation.
Thoughts?
Best,
Amit.
--
Amit Saha <http://echorand.me>
PnT DevOps - Developer
Red Hat, Inc.
8 years, 3 months