Bill Peck wrote:
Marian Csontos wrote:
> Hi Bill, Hi Kevin,
>
> Problem:
>
> 1. recipes contain task's _RPM_ name and _yum_ is expected to install
> the task
> It is easy to understand this Fedora-centric functionality: we are
> primary users of the tool.
>
> 2. Beaker is supposed to be used with _Windows_ machines too, to test
> e.g. JBoss, virtualization,...
> Is this rpm+yum approach portable to Windows?
> I have heard of cygwin, but let's keep the interface independent - in
> sake of modularity, extensibility, [ insert any other buzzword
> here... ;-) ]
>
> Suggested solution:
>
> What about using env.variable and executable in task instead of rpm tag:
> <<<<<
> - <rpm name="rh-tests-examples-testargs.noarch"/>
> =====
> + <params>
> + <param name="RPMPACKAGE"
> value="rh-tests-examples-testargs.noarch"/>
> + ...
> + </params>
> + <executable
url="http://host.name.org/path/to/executable"/>
> >>>>>
> ?
>
> The executable tag could take optional positional arguments - arg tag.
> The url argument is URL of a task-adaptor (e.g. rhts-task-adaptor).
> In our case it will:
> - set-up yum repository
> - download and install a test-file
> - run the test-file,
> ...which in case of RHTS tests means:
> - set the environment - e.g. RESULT_SERVER
> - run the task (make run in this case)
> - capture XML-RPC calls and
> - and report events back to Harness
>
> -- Marian
>
Hello Marian,
I'm wondering if we should drop the yum/rpm idea altogether and maybe
adopt the way autotest is doing packaging.
http://autotest.kernel.org/wiki/PackagingDevelopers Yes, something like that.
Obviously we would still support adding yum repos to distros that
support them, but we wouldn't use yum or rpm to install the
tasks/tests themselves.
But all of this should be done in the next version. I think we will
need to stay backward compatible for a while no matter what.
Backward compatible
with what? Harness does not care. LC does not care.
Current Scheduler implementation does, but it is not necessary to
propagate this dependency to LC.
While it is easy to write a backend which is task format dependent, it
is Scheduler who knows the type of the test/task.
The only thing depending on the test/task type should be TaskAdaptor.
The most flexible and powerful format I can think of is an
executable/script.
At the moment, all tasks (legacy RHTS tests) could use single script -
(modified) rhts-test-runner.sh or a wrapper.
Cheers,
-- Marian