On 03/09/2013 04:16 AM, Don Zickus wrote:
I am presenting these patches as a starting point for discussions as
to how Jan
and myself solved various problems. They are very much 'beta' patches (there
has been a lot of testing so they were stable at one point).
Thanks for posting these Don. From the Beaker side, Dan and Bill have
done a lot of work recently on providing a better solution to various
aspects of the bootstrapping problem, especially how to get harnesses
other than beah up and running after the system has been provisioned.
In Beaker 0.12 (due late March/early April), we'll be publishing a
provisional release of a future "Stable Harness API", as an alternative
to the private lab controller XML-RPC API used by beah.
The draft documentation for the new alternative harness mechanism is
For bootstrapping purposes, the key elements are:
1. The recipe definition must include the appropriate ks_meta setting so
Beaker knows what to pass to the alternative harness "yum install
<harness>" command in the kickstart %post
2. On installation, the alternative harness must arrange for itself to
execute automatically on the next reboot.
3. When it actually starts up, several environment variables are
provided so the harness can access the lab controller and the main
beaker server, including the ID of the recipe being executed on this
system. It is up to the harness to use those variables and the public
Beaker APIs to execute the tests and report the results appropriately.
In regards to 3, the recipe definition must still include at least one
task definition, even for alternative harnesses that don't rely on
Beaker's task library. In such cases, the params field of the mandatory
first task can be used to pass additional configuration options to the
While the API has been moved from XML-RPC to resources+collections
RESTful HTTP, it is currently still based on a combination of XML (for
GET operations) and HTTP form encoding (for PUT and POST operations).
Since our initial target is alternative harnesses that have already done
the work to interface with the XML-RPC API, we figure this is a good
incremental approach to getting something published for field-testing.
I'd like to move to JSON eventually, but that will require quite a bit
more design work.
The design proposal that was used to guide the implementation is also
The most interesting part of that is the "Deferred Features" section -
things we'd like to do eventually, but only after people have had a
chance to use and give feedback on the initial iteration of the design.
The rest of it has been updated to reflect the actual implementation,
since there were a few aspects that turned out to be a bad idea (or more
complicated than we thought) when Dan went to implement them.
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (http://beaker-project.org/
PulpDist Development Lead (http://pulpdist.readthedocs.org