----- Original Message -----
From: "Dan Callaghan" dcallagh@redhat.com To: "Beaker Devel" beaker-devel@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@redhat.com Software Engineer, Infrastructure Engineering and Development Red Hat, Inc.
Beaker-devel mailing list Beaker-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/beaker-devel