On Mon, Mar 11, 2013 at 10:47:53AM +1000, Nick Coghlan wrote:
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
here:
http://beaker-project.org/docs-develop/alternative-harnesses/index.html
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
Nice.
2. On installation, the alternative harness must arrange for itself
to execute automatically on the next reboot.
Yup.
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.
I was using some of them before.
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 alternative harness.
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 available:
http://beaker-project.org/dev/proposals/harness-api.html
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.
Hmm. Now the problem is, how do I test/play with the API to make sure I
code things properly. According to Bill, this API won't be live until
0.12. 0.12 won't be available to test on until end of April. :-(
Bill suggested using an internal Beaker instance of 0.12, but it doesn't
build. :-(
I guess it isn't good to start things on a Monday? ;-)
Cheers,
Don