On 08/09/2013 12:27 AM, Don Zickus wrote:
> On Sun, Aug 04, 2013 at 11:52:41PM -0400, Nick Coghlan wrote:
>> Hi Don, Bill, LMR,
>>
>> I saw that the pull request for Beaker harness API support in autotest has been
merged. I'd like to link to that feature from
beaker-project.org, so I was wondering
if there was anything published anywhere (even a blog or mailing list post) that covered
the details of:
>>
>> 1. What to add to a job/recipe definition to specify autotest as the harness
>> 2. What, if anything, to add to the task list in the recipe to configure
autotest appropriately
>> 3. What, if anything, to include in an autotest job to make it suitable for
running inside Beaker
>> 4. How the result reporting works when using autotest as a harness inside Beaker
(Do the results just go to Beaker? Or does normal autotest reporting still happen as
well?)
>>
>> If there isn't, we'd be happy to accept a patch on Gerrit to add an
autotest section to
http://beaker-project.org/docs/alternative-harnesses/ :)
>>
>> Somewhat related, is there a tentative date yet for the next autotest release?
>
> Yeah I will have to sit down and write one up. There were still a couple
> of quirks with the workflow (rebooting for one), that I need to iron out.
> But I am hoping to re-visit that stuff soon in the next couple of weeks.
> I need to wrap up another project first.
Ping :)
Even a cursory blog post somewhere (or a reply to this email!)
explaining to people how to *experiment* with this would be helpful. At
the moment I'm having to point people at the merged pull request to say
"Yes, in theory, you can use the upcoming version of autotest as a
Beaker test harness", but I have zero resources to give them on how to
actually run it (because I don't actually know myself).
1. How do you get the experimental version of autotest to play with? Is
there a pre-built RPM somewhere that people can use, or do they have to
build their own?
2. What do you need to set as the alternative harness in
http://beaker-project.org/docs/alternative-harnesses/#selecting-an-altern...
?
3. What's known to work, what's still quirky? (e.g. reboot)
4. What's different (if anything) compared to normal usage of autotest?
At the moment, it's impossible for even the core Beaker team to help
with this (let alone anyone else that may be interested), as we don't
even know how to get set up to run it.
I'd also like to submit a talk on Beaker to the Continuous Integration
miniconf at LCA, and that becomes a lot more compelling when I can point
to a post about *how* to run autotest inside Beaker, rather than just to
the pull request that made it possible.
Hmm, I am trying to figure out the workflow I had. Logging back into my
old systems is slowly jogging my memory. Let me beat on it some more.
Most of my workflow was using beaker tests, so something like
autotest-local bootstrap <
file>
would download the remote xml, convert it to a control file and then run
it. Or if it didn't run it, 'autotest-local list' was supposed to show
the control to run with 'autotest-local run <control file>'.
I'll work on it tomorrow.
Now that the new api has been released for a while and upstream autotest
has most of my code (if not all), then I can simplify my kvm environment
to a normal environment and play with it there.
Cheers,
Don