On 02/21/2013 02:23 PM, Dan Callaghan wrote:
Excerpts from Nick Coghlan's message of 2013-02-21 11:51:50
+1000:
> A task library based harness migrating to the stable API can easily do
> "RECIPEID = BEAKER_RECIPEID" for compatibility with existing tasks.
Right, or to be more precise I would say, a harness that supports
"RHTS-format tasks" can do that. There are plenty of people who are
interested in running the same old tasks, just from git directly.
"RHTS-format tasks" is a bit of a mouthful, but it works for me.
> 1. providing BEAKER_LAB_URL means harnesses migrating from the
old
> XML-RPC API can work around any gaps in the stable API rather than it
> being an "all-or-nothing" transition
Well I don't think we should care about this. Right now anyone who is
talking to the XML-RPC API has already hardcoded it as
http://$LABCONTROLLER:8000/. Or I guess you are saying, at least we can
encourage them to change it to $BEAKER_LAB_URL without forcing them to
also switch to the completely different HTTP API?
I'm more thinking about how we tell the reference harness the lab
controller details so it can set LABCONTROLLER for backwards
compatibility with RHTS-format tasks.
Perhaps BEAKER_LAB_FQDN would be a better value to provide to the harnesses?
> 2. providing BEAKER_HARNESS_API preserves *our* flexibility in
the
> overall URL design of the lab controller
Hmm maybe. I am worried we are introducing a false distinction though,
between "HTTP resources exposed by the lab controller for harnesses" vs
"HTTP resources exposed by the lab controller for test systems". Just
because something is currently handled by the harness (as opposed to,
a kickstart %post script or something) doesn't mean it always will or
won't be.
Do we need to address that now? Or can we leave it until we're looking
more closely at provisioning other distros and operating systems?
My original suggestion of BEAKER_API is still on the table, though - in
the long run, the stable API should provide all the interaction with
Beaker that is needed by anything running on a provisioned system,
whether that's part of the harness or part of a running task.
A truly hypertext/RESTful view would be that it's not even an
API, but
rather just a collection of HTTP resources exposed at well-known names.
It shouldn't matter whether it's a harness or some other piece of code
using them.
Maybe it is a mistake to even call it a "harness API" at all? I think of
it more as "lab controller HTTP resources which happen to be useful for
the harness", though that makes for a more awkward document title. :-)
I wouldn't worry about it - REST API is well accepted as a term, even
though you're right that it's technically a "collection of resources and
collections with HTTP as the API". (In reality, more complex situations
seem likely to add a "/actions/whatever" subresource to get more verbs
than the limited set offered by HTTP).
That said, the harness itself *doesn't* need to know the
server's URL
for this, it's preconfigured in /etc/yum.repos.d. The env var BEAKER is
set for tasks, but the harness doesn't use it. And since we don't want
to encourage the harness to talk to the server directly, we should just
drop it from the API altogether.
Don't we need to provide it anyway, so BEAKER can be set correctly for
RHTS-format tasks?
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)