Defining a harness API
by Dan Callaghan
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
* 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.
11 years, 3 months
- 5
- 10