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
>> 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
> 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
> 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
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:
> 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
To clarify, I was trying to build the latest develop branch in brew so I
could spin up a beaker in beaker instance.
No Package Found for python-sphinxcontrib-httpdomain