Excerpts from Bill Peck's message of 2013-02-21 12:12:52 +1000:
I was thinking about what you said about not implementing the
localhost xmlrpc interface. I'd like the harness to work
independently from beaker and be able to record results without being
tied to beaker too. The main reason for this is so that when
developing tests they run/execute exactly the same as they would in
the automated environment. When running locally we want the results
stored locally, probably recorded in the recipe.xml.
I don't think we need to implement the localhost xmlrpc interface to get
this behaviour, maybe use local sockets? Any other thoughts?
Yes I was trying to think of a good way to deal with this problem of
emulating the rhts-* commands. My current thinking is that the harness
should inject an extra directory (e.g. /usr/lib/restraint/rhts-emul) at
the start of PATH when it executes the tasks. That directory will have
compatible replacements for the rhts-* commands, supplied by the
harness, which use harness code to call out to Beaker or whatever else
is needed.
Then, if you want to run a task in "local" mode, you just inject
a different directory into PATH which points at a different
implementation of the rhts-* commands which send their output to disk
somewhere instead of to Beaker.
Two problems I can think of with PATH fiddling:
* any tasks that hardcode the full path to /usr/bin/rhts-* will break
* some people might not be happy that PATH has been polluted (as in,
doesn't match what the distro would normally give)
Alternatively, the harness could put its implementations of the rhts-*
commands into /usr/bin and just devise some mechanism of controlling
them through a bunch of environment variables (RESTRAINT_LOG_TO_DISK,
etc). Major downside to this is that those RESTRAINT_* variables pollute
the environment of the tasks.
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.