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