----- Original Message -----
From: "Dan Callaghan" <dcallagh(a)redhat.com>
To: "Beaker Devel" <beaker-devel(a)lists.fedorahosted.org>
Sent: Wednesday, December 19, 2012 4:46:19 PM
Subject: [Beaker-devel] Defining a harness API
An important first step towards supporting alternative harnesses
the mythical Beaker Simple Harness is coming up with a stable,
documented API for the harness to interact with Beaker. So I'm
this thread now to get the ball rolling.
My first thoughts:
* It should have the smallest possible surface area -- just enough to
expose all of Beaker's functionality and nothing more.
* It should be defined from the point of view of lab controller <->
system, not scheduler <-> test system. Corollary: we might need to
start treating the lab controller as a first-class citizen instead
just a dumb proxy to the scheduler.
* Just because we use XML-RPC now doesn't mean it's the best choice,
and doesn't mean we need to keep using it.
* In particular, the HTTP protocol probably supports everything we
to build the API (in other words, it can be a "RESTful API" even
though I hate that phrase). For example logs could be uploaded
HTTP PUT (with Content-Range), which means if we wanted we could
potentially use Apache mod_dav_fs to efficiently write these
to the filesystem without any intervening Beaker code.
There are four areas the API needs to cover (that I can think of).
harness needs to be able to:
* find out what to run
* report results and upload logs
I don't think results should be a necessity. I wonder if the LC should only
require the API to expose a way of setting the status of a task. e.g.
Because the UI of beaker is pretty tightly coupled to the idea of a result,
perhaps we would have to provide some default which indicates no
particular result either way, e.g N/A.
People who would be comfortable using beaker in this way would just be using
it for it's inventory resources, scheduling algorithms, and provisioning capablities,
and would be interested in sending their test results and logs elewhere.
Of course I don't imagine this to be the majority of use cases, and people
would also be able to upload a result and logs as per normal, but I don't
think it should be necessary.
* extend the watchdog time
* synchronize with other recipes in the recipe set
This last area is a new one, it's currently handled entirely in beah
there is no API on the Beaker side for it. But the dynamic FQDNs in
Beaker 0.10 mean it is now needed, even if it's as simple as having
a call to wait for all other harnesses in the recipe set to check in.
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.
Beaker-devel mailing list