From dcallagh at redhat.com Wed Aug 19 16:54:29 2015 Content-Type: multipart/mixed; boundary="===============5785229383716988431==" MIME-Version: 1.0 From: Dan Callaghan To: beaker-devel at lists.fedorahosted.org Subject: Re: [Beaker-devel] [RFC V3 PATCH 0/5] beaker harness support for autotest Date: Mon, 15 Apr 2013 17:39:18 +1000 Message-ID: <1366010178-sup-8988@galangal.usersys.redhat.com> In-Reply-To: 1365793793-121077-1-git-send-email-dzickus@redhat.com --===============5785229383716988431== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Excerpts from Don Zickus's message of 2013-04-13 05:09:48 +1000: > Hi Folks, > = > Throwing this over the wall for a new round of reviewing. Thanks for all your work on these patches, Don! I had a look through them all this afternoon (I'm sorry it's taken me so = long to get to it). I see there is a fair bit of code in there to = support running existing Beaker/RHTS-style tasks inside autotest = (emulating rhts-* commands, etc). I didn't realise that before. Using autotest to run existing Beaker tasks is interesting and may be = worth pursuing, but what's *more* interesting to us is the ability to = run autotest tests as part of a Beaker recipe. We've had some interest = from people who have existing autotest-based tests who would like to = make use of Beaker's scheduling abilities. Given my very limited understanding of autotest, this is what I was = imagining we would need to do: * Find a way to map native autotest control files to Beaker recipe XML. = The control files are real Python code, which makes them very = powerful, so I don't think it makes sense to try to abstract that away = in Beaker's XML. It might make more sense to allow the control file to = be embedded literally in the recipe XML. For example we could add = support for something like this: ... where