Hi Dan,
----- Original Message -----
From: "Dan Callaghan" <dcallagh(a)redhat.com>
To: "Beaker Devel" <beaker-devel(a)lists.fedorahosted.org>
Cc: "Min Shin" <mishin(a)redhat.com>
Sent: Wednesday, February 6, 2013 5:59:51 PM
Subject: Re: Defining a harness API
Excerpts from Dan Callaghan's message of 2012-12-20 14:50:15 +1000:
> First sketch of an HTTP API below. I don't think I've forgotten
> anything...
I've just uploaded a patch series to Gerrit which implements most of
this draft API:
http://gerrit.beaker-project.org/1703
http://gerrit.beaker-project.org/1704
http://gerrit.beaker-project.org/1705
http://gerrit.beaker-project.org/1706
along with a few supporting changes:
http://gerrit.beaker-project.org/1242
http://gerrit.beaker-project.org/1701
http://gerrit.beaker-project.org/1702
As an added bonus, there are also tests covering the existing XML-RPC
API.
A few things are still missing:
* recipe synchronization
* "N/A" result type, and attaching URLs to results (as discussed
elsewhere on this thread)
* API docs for the new harness API
* release notes for the log storage change
But, I think it's close enough that we could include it as an
"experimental" API in 1.0, which people developing harnesses can
start
working with. Min, how does that sound to you?
Thanks for pushing this. I think this and an actual harness implementation project that we
are trying to kick off will complement each other well.
Please make sure to add some design documents and minimum API documentation if possible.
Regards,
Min
> Excerpts from Dan Callaghan's message of 2012-12-19 16:46:19 +1000:
> > There are four areas the API needs to cover (that I can think
> > of). The
> > harness needs to be able to:
> >
> > * find out what to run
>
> Get recipe XML:
>
> GET /recipes/{recipeid}
> Accept: application/xml
>
> > * report results and upload logs
>
> Record a task result:
>
> POST /recipes/{recipeid}/tasks/{taskid}/results/
> Content-type: application/x-www-form-urlencoded
>
> path=/the/task/result&result=Pass&score=1234&message=It+worked
>
> -> 302 See Other
> Location: /recipes/{recipeid}/tasks/{taskid}/results/{resultid}
>
> Upload recipe log:
>
> PUT /recipes/{recipeid}/logs/{path...}
>
> Upload task log:
>
> PUT /recipes/{recipeid}/tasks/{taskid}/logs/{path...}
>
> Upload task-result log:
>
> PUT
> /recipes/{recipeid}/tasks/{taskid}/results/{resultid}/logs/{path...}
>
> These could accept Content-Range (for partial uploads) and
> Content-Type
> (which we could store and return later).
>
> > * extend the watchdog time
>
> Set watchdog to now + X seconds:
>
> POST /recipes/{recipeid}/watchdog
> Content-type: application/x-www-form-urlencoded
>
> seconds=X
>
> > * synchronize with other recipes in the recipe set
>
> Block until all other recipes in the recipe set (except guest
> recipes?)
> have called this, or until X seconds have elapsed:
>
> POST /recipes/{recipeid}/sync-start?timeout=X
>
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.