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
_______________________________________________
Beaker-devel mailing list
Beaker-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel

Reply via email to