I published an updated version of the proposal yesterday:
The key change is to treat it as "de-coupling" recipe-task definitions
from the task library. So a recipe-task will still always have a name,
but it is no longer required to reference a task in the library. It also
introduces a mechanism for the harness to update the task name at
Excerpts from Nick Coghlan's message of 2013-11-27 14:40:19 +1000:
I *don't* like the way the proposal refers to *removing* the
library. The task library isn't going anywhere, we're just providing a
way to bypass it when doing so makes sense. The task library is still an
incredibly convenient way to publish utilities like the standard tasks
and potentially future higher level utilities like properly configured
KDC, LDAP and qpid servers.
I deleted the mention of "removing" the task library and reworded it to
just explain all the benefits of not being tied to the task library.
Finally, I'd prefer it if the proposal was backed by a core
"/distribution/gitfetch" task, together with the ability to flag a task
in the task library as "external". When a task was flagged as external,
then Beaker would *require* that a "fetch" element exist, and would
display that URL when appropriate. Given the UI issues in the Beaker
0.15 upgrade, I'm concerned about breaking the fundamental assumption of
every task being associated with an entry in the task library. By using
an "external" flag and an implied task name (instead of leaving the task
library reference NULL), it changes the failure mode from failing to
handle an unexpected NULL or None value to display the task name as
usual rather than the desired URL details.
I don't think that requiring a particular fixed task name for external
tasks is a good approach. For one thing, it makes the results harder to
interpret since every external task has the same name. Also, trying to
make Beah transparently support external tasks using a shim "gitfetch"
task is not worth pursuing I think, so I added that as a deferred
I also don't think we need to be afraid to evolve Beaker's data model
like this (making a relationship optional). We have quite good test
coverage, especially of the web UI, so the risk of "NoneType has no
attribute..." errors slipping in is low.
External interfaces, like the job results XML which can be consumed by
other tools, are a legitimate concern though. But in the updated
proposal a recipe-task will always have a name, so I think this allows
us to avoid breaking compatibility on external interfaces.
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Hosted & Shared Services
Red Hat, Inc.