On 02/21/2013 09:40 AM, Dan Callaghan wrote:
> The initial draft of the alternate harness design has the XML
look like
> this:
>
> <recipe ks_meta="harness=mylittleharness">
> <repos>
> <repo name="mylittleharness"
>
url="http://example.com/mylittleharness/el6/" />
> </repos>
> ...
> </recipe>
>
> However, this leaves in place the current requirement that every recipe
> definition must include at least one task, and doesn't provide a task
> library independent way to request reservation of the system after the
> recipe executes.
In case it's not clear, my proposed way of selecting alternative
harnesses would be a patch of approximately 5 lines to the rhts_post
template. Everything else is built on existing Beaker features. So it
has the distinct advantage of being easy and non-intrusive to implement.
> My alternative suggestion is
[...]
>
> At the harness level, the interesting parts would be:
>
> 1. The required "yuminstall" attribute of the harness element replaces
> the ks_meta="harness=<yum arg>" part of Dan's initial design
> The explicit nature of the "yuminstall" name leaves the door open to
> less packaging system specific alternatives in the future
Well, as long as ks_meta exists we are tied to yum anyway :-) The real
issue here is not that the variable "harness=package_or_url" is tied to
yum, but that ks_meta itself it.
The way forward I see is that ks_meta ("Kickstart Metadata") becomes
"Installer Template Variables". They become a cross-installer way for
people to customise the installation -- Beaker takes care of translating
those variables into whatever syntax and meaning is appropriate for the
installer. In that case having a variable "harness=something" is not
yum-specific at all.
That makes sense. Lets run with your ks_meta approach for now, and we
can look at something different as part of the exploration of image
based testing and cross-platform support.
> 2. The optional "label" attribute gives us something
human readable to
> show in the UI (defaulting to the "yuminstall" value)
I do like this idea of having some nice way to display "what harness ran
this recipe" in Beaker's UI, but requiring the user to give a label in
every recipe is not great. We could just display the package name as is
(or the basename if it was a full URL).
A nicer idea might be to have the harness "check in" at the start of the
recipe, report its name and version (and its configuration, and other
useful info too?) -- Marian Csontos has suggested something similar in
the past, and you can already get most of the way there by just having
the harness upload a recipe log under a certain well-known name
("debug/harness-checkin.txt" or whatever).
A check-in API sounds good to me.
Perhaps it could be considered as a possible replacement for our current
install-done callback, that we hit from the kickstart file with wget or
curl?
> 3. The ability to request reservation of the system after
execution of
> the recipe is separated out from the definition of what the harness
> should do
> 4. "reservesys" is an *element* to leave the door open to possible
> future feature like <reservesys onsuccess="false"> to only reserve it
in
> some cases.
+1000 to this, except as mentioned it doesn't need to be tied to this
harness proposal at all.
Yeah, good point. I've filed an RFE as
https://bugzilla.redhat.com/show_bug.cgi?id=913339
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (
http://beaker-project.org/)
PulpDist Development Lead (
http://pulpdist.readthedocs.org)