I decided it made more sense to publish Bill's external tasks library on beaker-project.org and start a thread here, rather than continue to conduct the high level design discussions in the Gerrit review.
Firstly, I like the idea of "fetch" and "rpm" nodes in the task XML. The proposal should be more explicit about the fact that the RPM node is only present in the recipe XML when it is retrieved through the stable harness API, and not in other cases (such as when cloning a job).
I *don't* like the way the proposal refers to *removing* the task 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 (http://beaker-project.org/docs/user-guide/beaker-provided-tasks.html), and potentially future higher level utilities like properly configured KDC, LDAP and qpid servers.
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.
Regards, Nick.
I published an updated version of the proposal yesterday:
http://beaker-project.org/dev/proposals/external-tasks.html
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 runtime.
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 task 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 (http://beaker-project.org/docs/user-guide/beaker-provided-tasks.html), 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 feature.
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.
beaker-devel@lists.fedorahosted.org