I've just published the initial version my design proposal for a stable
harness API [1], following Beaker's new design proposal process. The API
it describes is mostly the same as my original draft from an earlier
thread on this list [2]. I added a "none" result ("N/A" was awkward
because of the slash and "Not Applicable" because of its two words) and
a way for the harness to attach arbitrary URLs as logs, as suggested by
Bill [3].
The other additions are the part about how Beaker configures the
harness, and how users will be able to select an alternative harness.
I'm particularly interested in feedback about the post-install
configuration part. I based the /root/RECIPE.TXT file and the
environment variables on what we have now, but they are not necessarily
the nicest way to do it. As I see it, passing information on the
filesystem could be problematic because it's not cross-platform (the
path would have to be different on Windows) and it might give us SELinux
headaches. On the other hand, passing information by environment
variables will work cross-platform but it is much harder for Beaker to
actually *set* the variables in a cross-platform way. Right now we are
relying on /etc/profile being sourced, which is okay for SysV init since
the scripts are in bash, but systemd services are started with a clean
environment and so we would need to somehow get the env vars into the
right unit file. And it would be different again on the other platforms.
So I'm not really sure what the best way is.
I think Nick also has some suggestions about the alternative harness
selection too... so, let the discussions begin!
Coming soon: my "reference harness" proposal to go along with this
one...
[1]
http://beaker-project.org/dev/proposals/harness-api.html
[2]
http://thread.gmane.org/gmane.comp.systems.beaker.devel/405
[3]
http://article.gmane.org/gmane.comp.systems.beaker.devel/416
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.