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 <dcall...@redhat.com> Software Engineer, Infrastructure Engineering and Development Red Hat, Inc.
signature.asc
Description: PGP signature
_______________________________________________ Beaker-devel mailing list Beaker-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
