Excerpts from Dan Callaghan's message of 2013-02-21 09:40:32 +1000: > > 1. Transport arbitrary XML configuration settings for the harness > > through the recipe definition > > Passing configuration from the recipe to the harness is definitely > a good idea, although I find using XML for configuration to be hateful.
Thinking about this some more, there is a lot of
"configuration"/"parameter"/information going back and forth in various
directions here, and it is worth clarifying it all.
Currently in Beaker:
Beaker -> harness
Sets up harness in kickstart %post (but no per-recipe
customization)
Recipe -> harness (augmented by Beaker task library)
<task/> elements in recipe, to which Beaker adds <rpm/> info
from task library
Recipe -> task (via harness)
Name-value <params/> in recipe, which harness translates to env
vars when running the task
Task -> harness (via Beaker task library)
Fields extracted from testinfo.desc which are stored by Beaker
and then fetched by the harness, these are generally name-value
pairs but some are multi-valued, and they have various semantics
The reference harness proposes changing the latter to be direct:
Task -> harness
Harness parses testinfo.desc directly
The biggest one missing is: recipe -> harness. It's worth distinguishing
between task-specific and recipe-specific harness configuration, they
are both useful.
For example, Petr Splichal wants to pass a list of packages to the
harness for each task in the recipe (so this is recipe-specific harness
configuration). He proposed passing it as task params, but you could
argue that is an abuse of their meaning (they are parameters for the
task, not for the harness running the task).
And then there is recipe-specific harness configuration. Beah doesn't
have much of this, apart from whether to enable debugging and whether to
run rhts-compat, and right now there is no clean way to control this in
the recipe. Alternative harnesses would have their own configuration.
So the latter is what Nick was trying to address with his idea of
putting arbitrary XML in the recipe and passing these to the harness.
But I wonder if we can't rationalise this a bit more, and come up with
some more consistent ways of passing this stuff around.
For example, the testinfo.desc format is well-entrenched and not likely
to change much, ever. Right now we treat it as a way for the task to
describe itself to Beaker, but really it is a way for the task to
describe itself to the harness running it. The only problem is that it's
static -- you can't augment any of that metadata on a per-recipe basis
(unless you branch/fork the task).
Would it make sense to allow the same testinfo.desc format and field
definitions in the recipe, as a way to override the metadata declared
inside the task? Then, if testinfo.desc expands to grow new fields in
future (e.g. RequiresTty: Yes/No) we automatically have a way to control
the same things on a per-recipe basis.
--
Dan Callaghan <dcall...@redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.
signature.asc
Description: PGP signature
_______________________________________________ Beaker-devel mailing list Beaker-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
