----- 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
and/or
the mythical Beaker Simple Harness is coming up with a stable,
documented API for the harness to interact with Beaker. So I'm
starting
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 <->
test
system, not scheduler <-> test system. Corollary: we might need to
start treating the lab controller as a first-class citizen instead
of
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
need
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
using
HTTP PUT (with Content-Range), which means if we wanted we could
potentially use Apache mod_dav_fs to efficiently write these
directly
to the filesystem without any intervening Beaker code.
There are four areas the API needs to cover (that I can think of).
The
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.
Running/Completed.
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
and
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.
Thoughts?
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.
_______________________________________________
Beaker-devel mailing list
Beaker-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel