On 12/21/2012 12:52 PM, Raymond Mancy wrote:
> * report results and upload logs
I don't think results should be a necessity. I wonder if the LC should only
require the API to expose a way of setting the status of a task. e.g.
Because the UI of beaker is pretty tightly coupled to the idea of a result,
perhaps we would have to provide some default which indicates no
particular result either way, e.g N/A.
People who would be comfortable using beaker in this way would just be using
it for it's inventory resources, scheduling algorithms, and provisioning
and would be interested in sending their test results and logs elewhere.
Of course I don't imagine this to be the majority of use cases, and people
would also be able to upload a result and logs as per normal, but I don't
think it should be necessary.
I'd think of this part of the API as "report progress" rather than
"report results". Even if they don't tell us whether or not the task
succeeded, they still need to tell us when it is done. For navigation
purposes, we may want to provide a way for alternate test
harnesses/result servers to add an "external results URL" at the
job/recipe/task level (with the appropriate granularity being an open
I like Dan's idea of using a REST-style API for the stable harness API,
and making the lab controller a more active participant in the process.
We're already moving that way in 0.11, with the lab controller
intercepting the clear netboot calls in order to execute them synchronously.
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (http://beaker-project.org/
GlobalSync Development Lead (http://pulpdist.readthedocs.org