From dzickus at redhat.com Wed Aug 19 16:54:29 2015 Content-Type: multipart/mixed; boundary="===============0541359907024910131==" MIME-Version: 1.0 From: Don Zickus 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 10:00:47 -0400 Message-ID: <20130415140047.GN79013@redhat.com> In-Reply-To: 1366010178-sup-8988@galangal.usersys.redhat.com --===============0541359907024910131== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, Apr 15, 2013 at 05:39:18PM +1000, Dan Callaghan wrote: > 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. Yeah. I was trying to leverage all the old tests to help me address all the kinks of the beaker interface. It would also make it easier to have devleopers utilize existing tests (as they are not going away any time soon). > = > 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. Of course. That part is fairly simple but would require me writing lots of tests to exercise all the beaker paths. See below. > = > 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: Long ago, Jan and I talked about just grabbing the tests straight from a git tree. Much simpler and straight forward than embedding scripts in the XML (ewww!). Bill P. has something like this working with his simple harness. The idea is to pass a known type of with a git url pointer that included the tesname and option control file. The harness would recoginize the autotest task, download the git tree or test and then execute the control file embedded in the test. > = > > ... > > > = > where